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1 Vorwort 


Mit der Version 5.5 von Borlands Turbo-Pascal Entwicklungssystem steht 
einem breiten Personenkreis die Möglichkeit zur Entwicklung objektorien- 
tierter Programme zur Verfügung. Bereits die Versionen 4.0 und 5.0 boten 
das Handwerkszeug zur Erstellung anspruchsvoller Programme, vor allem 
durch Einführung des UNIT-Konzeptes, durch die Möglichkeit zur Bildung 
von Overlays sowie durch die Bereitstellung eines leistungsfähigen symboli- 
schen Debuggers. 


Die bei der Erstellung professioneller, größerer Programmsysteme auftreten- 
den Probleme führten schon vor einiger Zeit zur Entwicklung von objektori- 
entierten Konzepten, wie sie z.B. in Reinkultur in der Programmiersprache 
Smalltalk realisiert sind. Die Verbreitung der Sprache blieb jedoch aufgrund 
bestimmter Spracheigenschaften im wesentlichen auf den akademischen Be- 
reich beschränkt. Erst die Vorstellung einer objektorientierten Version der 
Programmiersprache C verhalf der objektorientierten Denkweise zum 
Durchbruch. Nach anerkannter Lehrmeinung werden in Zukunft Objekte aus 
der Programmierung nicht mehr wegzudenken sein, teilweise werden kon- 
ventionelle höhere Programmiersprachen wie C und Pascal bereits als 
"Assembler der 90er Jahre" bezeichnet - für manche Spezialaufgabe noch er- 
forderlich, aber ansonsten überholt. 


Es lohnt also, sich mit der objektorientierten Programmierung auseinander- 
zusetzen. Turbo-Pascal 5.5 bietet die Möglichkeit, die Welt der Objekte mit 
wenig Aufwand kennenzulernen. Die vorhandenen Handbücher beschränken 
sich jedoch im wesentlichen auf die Beschreibung der Befehle und Bedie- 
nungsmöglichkeiten des Systems. Die mitgelieferten Beispielprogramme sind 
sicherlich interessant, sind aber für den unbedarften Anwender bei weitem zu 
kompliziert und können daher kein Ersatz für eine systematische Einführung 
in die objektorientierte Programmierung sein. 


Dieses Buch beschreibt zunächst die Sprachelemente der objektorientierten 
Programmierung, wie sie mit Turbo Pascal 5.5 zur Verfügung gestellt wer- 
den. Darauf aufbauend werden einfache Beispiele entwickelt, anhand derer 
objektorientiertes Denken vermittelt wird. Der Vergleich zur konventionel- 
len Implementierung erleichtert das Verständnis des objektorientierten An- 
satzes ganz wesentlich. Ausgerüstet mit diesen Grundkenntnissen kann sich 
der Leser an die Programmierung anspruchsvollerer Aufgaben wagen. Diese 
sind so gewählt, daß sie sich für die objektorientierte Programmierung be- 
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sonders eignen und gleichzeitig wertvolle Bausteine für eigene Entwick- 
lungen bilden. 


Der Einsteiger erhält eine systematische Einführung in die Welt der objekt- 
orientierten Programmierung, aber auch der Profi findet hier Anregungen für 
die tägliche Praxis. Voraussetzung zur sinnvollen Arbeit mit diesem Buch ist 
eine gewisse Minimalerfahrung mit dem Umgang mit Rechnern und dem 
Turbo-Pascal Entwicklungssystem. So wird z.B. davon ausgegangen, daß 
der Leser in der Lage ist, das Turbo-Pascal System auf seinem Rechner zu 
installieren und einfache Probleme in lauffähige Programme umzusetzen. Be- 
griffe wie Prozedur, Typvereinbarung, oder dynamische Speicherverwaltung 
sollten bekannt sein. Der Programmierneuling muß hier auf eines der zahl- 
reichen Einführungsbücher zu Turbo-Pascal verwiesen werden. 


Wer die in diesem Buch entwickelten Beispielprogramme nicht eintippen 
möchte, kann beim Autor eine Diskette mit dem Quelltext erhalten. 


Martin Aupperle 
St. Bonifatiusstr. | 
8000 München 90 


2 Einführung 


2.1 Schrittweise Verfeinerung 


Zum Entwurf eines Programms stehen heute bereits erprobte Verfahren zur 
Verfügung, die eine ingenieurmäßige Behandlung der bei der Entwicklung 
eines größeren Programms auftretenden Probleme ermöglichen. Diese Tech- 
niken basieren im allgemeinen auf dem Prinzip der Schrittweisen Verfeine- 
rung. Darunter versteht man die Unterteilung der Gesamtaufgabe in einfa- 
chere und kleinere Untereinheiten, die dann in der gleichen Weise wieder 
unterteilt werden, bis man bei so einfachen Strukturen angelangt ist, daß 
diese durch einen einzelnen Programmierer als Ganzes erfaßt und implemen- 
tiert werden können. Mit größer werdender Verfeinerung ergibt sich aller- 
dings ein Schnittstellenproblem, denn nur über diese Schnittstellen können 
die getrennt betrachteten Moduln miteinander kommunizieren. Bei jedem 
Verfeinerungsschritt wird also Struktur- oder Programmkomplexität auf Ko- 
sten der Schnittstellenkomplexität reduziert. Es gilt, das Problem so weit zu 
verfeinern, bis beide Größen einen akzeptablen Wert haben. 


Viele Verfahren, die auf der Technik der Schrittweisen Verfeinerung beru- 
hen, ermöglichen die arbeitsteilige Erstellung von Programmen. Darüber 
hinaus ist es möglich, die "Richtung" der Verfeinerung so zu steuern, daß 
Module wiederverwendbar sind, bzw. daß umgekehrt auf bereits vorhandene 
Elemente zurückgegriffen werden kann. Das Problem der Schnittstellenkom- 
plexität bleibt jedoch weiterhin bestehen. 


2.2 Objektorientierter Entwurf 


Beim objektorientierten Entwurf strebt man an, als Ziel der Schrittweisen 
Verfeinerung sogenannte Objekte zu erhalten. Ein Objekt löst dabei eine 
(oder mehrere) im Rahmen der Schrittweisen Verfeinerung genau definierte 
Aufgabe(n). Die dazu erforderlichen Daten und die auf diese Daten wirken- 
den Algorithmen sind beides Teile des Objekts. 
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Objekte kommunizieren untereinander über den Austausch von Nachrichten. 
Empfängt ein Objekt eine Nachricht, aktiviert es die zugehörigen Algorith- 
men, die evtl. wieder andere Nachrichten erzeugen. Das Objekt wird dabei 
als abgeschlossene Einheit betrachtet, dessen Inneres den anderen Objekten 
unbekannt ist. Weiterhin ist die in konventionellen Programmiersprachen 
immer vorhandene Trennung zwischen Daten und Verarbeitung aufgehoben. 
"Man denkt also nicht mehr "prozedural" oder "datenorientiert", sondern pro- 
.blemorientiert. Die für die Lösung des Problems erforderlichen Daten UND 
Algorithmen werden zu einer Einheit untrennbar verbunden, eben dem Ob- 
jekt. Eine Folge davon ist, daß - wie wir sehen werden - die Daten eines Ob- 
jektes nicht mehr als Parameter an die Algorithmen des Objektes übergeben 
werden müssen, sondern diesen implizit zur Verfügung stehen. 


Mit dieser Technik lassen sich wiederverwendbare Bausteine erstellen, die - 
in Analogie zur Hardware - auch Software-ICs genannt werden. Sie können 
nämlich von einem Programmentwickler in gleicher Weise wie ihre materi- 
ellen Gegenstücke miteinander kombiniert werden, wenn nur die Schnitt- 
stellenspezifikationen eingehalten werden. Wie das IC intern aufgebaut ist, 
spielt dabei keine Rolle. 


2.3 Vererbung 


Objekte sind auch noch in anderer Weise wiederverwendbar. Sie können 
nämlich zur Definition weiterer Objekte herangezogen werden. Dabei "erbt" 
das neu zu definierende Objekt automatisch die Eigenschaften seines Vor- 
gängers, d.h. das abgeleitete Objekt besitzt automatisch alle Datenelemente 
und Algorithmen seines Vorgängers. Für abgeleitete Objekte werden dann in 
der Regel nur noch zusätzliche Eigenschaften (in Form weiterer Daten und 
Algorithmen) definiert; es ist jedoch auch möglich, vom Vorgänger über- 
nommene Verarbeitungselemente zu re-definieren. 


2.3 Vererbung R) 


Schrift- 
stück 


Belletristik 


Bild 2-1 : Objekthierarchie 


In Bild 2-1 wird das Objekt Schriftstück zur Definition der Objekte Buch, 
Zeitschrift und Zeitung verwendet. Buch erbt dabei alle Eigenschaften von 
Schriftstück und kann zusätzlich neue Eigenschaften definieren. Übernom- 
mene Eigenschaften wären z.B. die Art der Repräsentation des Inhaltes in ei- 
nem Rechner (Datenelement) oder ein Algorithmus zur Darstellung auf dem 
Bildschirm (Verarbeitungselement). Eine neudefinierte Eigenschaft für Buch 
könnte z.B. die interne Gliederung in Kapitel und Abschnitte sein. Diese Ei- 
genschaft unterscheidet auch ein Buch von einer Zeitschrift, denn in Zeit- 
schriften wird man immer eine andere Gliederung des Inhaltes vorziehen. 


Beim Entwurf einer Objekthierarchie werden durch die Hinzunahme weiterer 
Eigenschaften abgeleitete Objekte immer genauer bestimmt, bis der ge- 
wünschte Detaillierungsgrad erreicht ist. Dabei versucht man, die Eigen- 
schaften so zuzuweisen, daß sich die Objekte möglichst gut voneinander un- 
terscheiden lassen. Eigenschaften, die für mehrere Objekte gleich sind, soll- 
ten in das gemeinsame Vorgängerobjekt verlegt werden. Kommt etwa in der 
gezeigten Objekthierarchie die Anforderung zur Übertragung über eine seri- 
elle Schnittstelle hinzu, wird man diese Eigenschaft nicht für Buch, Zeit- 
schrift und Zeitung getrennt, sondern möglichst zentral für Schriftstück ent- 
werfen. 


Auf diese Weise können ganze Objekthierarchien gebildet werden, wobei je- 
des abgeleitete Objekt eine Spezialisierung seines Vorgängers darstellt. 
Abgeleitete Objekte bleiben dabei mit Ihren jeweiligen Vorgängern fest ver- 
bunden: Werden die Eigenschaften des Vorgängers geändert, wirkt sich dies 
auch automatisch auf alle Nachfolger aus. Wenn die Objekthierarchien in der 
Entwurfsphase geeignet gewählt wurden, können Änderungen, die mehrere 
Objekte betreffen, auf das gemeinsame Vorgängerobjekt beschränkt werden. 
Durch eine "gute" Objekthierarchie wird daher die Anderungsfreundlichkeit 
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eines Programms wesentlich beeinflußt. Der Definition dieser Hierarchien 
muß deshalb beim Entwurf des Programmsystems bereits besonderes Au- 
genmerk gewidmet werden. 


2.4 Weitergehende Möglichkeiten 


Damit sind die neuen Gestaltungsmöglichkeiten, über die der Programmierer 
bei Verwendung von Objekten verfügen kann, noch lange nicht erschöpft. 
Konzepte wie "virtuelle Methoden" oder "Polymorphismus" sind wirkungs- 
volle Mechanismen für eine weitere Produktivitätssteigerung bei der Soft- 
wareentwicklung. Sie sind jedoch in Ihrer Mächtigkeit erst dann verständ- 
lich, wenn die Grundlagen objektorientierter Denkweise vorhanden sind. 


2.5 Objektorientierte Programmierung 


Objektorientierter Entwurf befaßt sich hauptsächlich mit dem Entwurf von 
Objekten, deren Interaktion untereinander sowie mit dem Aufbau von Ob- 
jekthierarchien. Die Programmiersprache, in der diese Strukturen dann im- 
plementiert werden, spielt dabei zunächst keine oder eine nur untergeordnete 
Rolle. Objektorientierte Programmierung hingegen geht von bereits defi- 
nierten Objekten, Beziehungen und Hierarchien aus und versucht diese Vor- 
gaben in einer Programmiersprache abzubilden. Hier spielen die von der 
Sprache bereitgestellten Sprachmittel eine größere Rolle, denn nicht alle ob- 
jektorientierten Sprachen stellen die gleichen Konstrukte bereit und sind da- 
her zur Implementierung auch nicht gleich gut geeignet. Im allgemeinen gilt 
auch hier, daß für Programme mit speziellen Laufzeit- oder Speicherplatzan- 
forderungen die Sprache C geeigneter, für andere Aufgaben Pascal, Modula 
oder eine andere Sprache vorteilhafter sein mag. Oftmals ist es auch möglich, 
verschiedene Sprachen zu mischen, also "hybrid" zu programmieren. Denk- 
bar wäre z.B. eine Codierung von maschinennahen Teilaufgaben in C und die 
Programmierung von höheren Datenstrukturen z.B. in Pascal. Beschränkt 
man sich auf Borlands Turbo-Familie, kann den Objekten auf einfache Weise 
sogar eine gewisse Intelligenz verliehen werden, indem man eine Verbindung 
mit Turbo-Prolog herstellt. 


Objektorientierte Entwicklung und objektorientierte Programmierung sind 
nur in der Theorie zwei getrennt aufeinanderfolgende Phasen. In der Praxis 
werden beide Tätigkeiten oft mehr oder weniger gleichzeitig ausgeführt. 
Trotzdem bedingt die objektorientierte Programmierung immer auch einen 
objektorientierten Entwurf. Es ist wenig sinnvoll, in einem weit fortge- 
schrittenen Entwicklungsvorhaben auf objektorientierte Programmierung 
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umzustellen, ohne einen großen Teil der Entwicklungsphase wiederholen zu 
müssen. Objektorientierte Programmiertechniken können nur sinnvoll einge- 
setzt werden, wenn auch wirklich von vornherein Objekte, Hierarchien etc. 
definiert wurden. 


Auch hieraus geht hervor, daß der geeigneten Definition von Objekten und 
ihrer Beziehungen untereinander eine zentrale Bedeutung zukommt. Mehr 
noch als in traditionellen Entwicklungstechniken ist hier eine sorgfältige Ar- 
beit in der Vorphase der Programmierung der Schlüssel zum Erfolg. 


2.6 Objektorientiertes Programmieren und 
Turbo-Pascal 


Die Sprache Pascal wurde ursprünglich von Professor Wirth zu Lehrzwecken 
entworfen. Ihre weite Verbreitung verdankt sie wohl zum großen Teil der 
Firma Borland, die die magere ANSI-Spezifikation der Sprache zu einem 
professionellen Programmentwicklungssystem inclusive Editor und interakti- 
vem Debugger ausgebaut hat. Was liegt also näher, als sich auf den ur- 
sprünglichen Zweck der Sprache zu besinnen und objektorientiertes Pro- 
grammieren mit Turbo-Pascal zu lernen? Nach der Lektüre dieses Buches be- 
sitzt der Leser ein Grundwissen, mit dem er objektorientierte Konstrukte an- 
derer Sprachen verstehen und sinnvoll einsetzen kann. 


2.7 Zusammenfassung 


Objektorientierter Entwurf ist eine Programmentwicklungstechnik auf der 
Grundlage der Schrittweisen Verfeinerung. Objekte können dabei so entwor- 
fen werden, daß sie einerseits wiederverwendbar sind und daß andererseits 
die Schnittstellenkomplexität reduziert wird. Beide Effekte führen zu einer 
weiteren Effizienzsteigerung gegenüber konventionellen Entwicklungsme- 
thoden, insbesondere wenn größere Programme entwickelt werden müssen. 


3 Objekte: Daten und 
Algorithmen 


3.1 Probleme in traditionellen Sprachen 


Ein Grundprinzip in konventionellen prozeduralen Sprachen ist die Trennung 
von Daten- und Verarbeitungselementen. Die Verarbeitungselemente sind 
traditionell in Form von Prozeduren oder Funktionen organisiert, und sie er- 
halten die Daten, auf denen sie arbeiten sollen, als Parameter übergeben (den 
Fall des Zugriffs auf globale Daten lassen wir zunächst außer acht). Meist 
werden Prozeduren sogar so entworfen, daß sie an verschiedenen Stellen des 
Programms mehrfach, meist mit verschiedenen Daten, aufgerufen werden 
können. Mehrfach gebrauchte Programmteile werden also zusammengefaßt 
und getrennt vom restlichen Programm als Prozedur abgelegt. Als Endeffekt 
kann man ganze Bibliotheken von Prozeduren erhalten, die allgemeingültige 
Aufgaben lösen sollen. Die zahlreichen angebotenen Toolboxen.sind ein Bei- 
spiel hierfür. — 


Algorithmen in Form von Prozeduren benötigen jedoch auch Daten. Diese 
werden im allgemeinen als Parameter übergeben, da sie - historisch bedingt - 
im Programm an anderer Stelle als die Prozeduren deklariert sind. Die Ver- 
bindung zwischen beiden wird erst beim Aufruf der Prozedur, wenn also die 
Formalparameter durch die Aktualparameter ersetzt werden, vorgenommen. 
Diese Trennung ist jedoch willkürlich und nur deshalb so allgegenwärtig, 
weil wir es so gelernt und immer schon so gemacht haben. Schaut man einem 
Softwareentwickler in der Entwurfsphase bei der Arbeit zu, ergibt sich je- 
doch ein anderes Bild: Zu einem Problem notiert er die erforderlichen 
Verarbeitungsschritte und Datenelemente zusammen auf einem Blatt. Erst bei 
der Implementierung werden Daten und deren Verarbeitung voneinander ge- 
trennt, weil die Syntax der Programmiersprache es so vorschreibt. 


Hat man z.B. in einem Programm eine Funktion zur Klassifikation von Tem- 
peraturen geschrieben, ist es nicht sinnvoll, diese Funktion auch auf Gehälter 
oder gar auf Zeitstempel von Dateien anzuwenden, auch nicht wenn diese In- 
formation ebenfalls als Integer-Zahl abgespeichert ist. Traditionelle Compi- 
ler schützen jedoch vor solchen und einer Reihe ähnlicher Fehler nicht: Ist 
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eine Funktion mit einem Formalparameter vom Typ integer definiert, kann 
sie auch mit jedem beliebigen Integerwert aufgerufen werden. Die 
numerische Manipulation des übergebenen Wertes wird durchgeführt, 
unabhängig davon, ob es sich um eine Temperatur oder ein Einkommen 
handelt. 


Dieses Problem ist bis zur Trivialität vereinfacht und läßt sich sicherlich 
durch geeignete Programmierung vermeiden. Das grundlegende Problem 
bleibt jedoch erhalten und kann höchstens mehr oder weniger verdeckt wer- 
den. Kurz gesagt besteht es in folgendem Sachverhalt: 


In traditionellen Sprachen kennt der Compiler nicht die Interpretation 
eines Datenelementes. Diese ist nur dem Programmierer bekannt. 
Der Programmierer muß daher anhand dieses Wissens die richtigen 
Verarbeitungsschritte mit den richtigen Datenelementen kombinie- 
ren. 


Hier setzt einer der zentralen Gedanken der objektorientierten Programmie- 
rung an: Warum nicht die Temperaturvariable mit der Klassifikationsfunktion 
für Temperaturen zusammen als eine Einheit deklarieren? Damit wäre die: 
Anwendung dieses Klassifikators auf ungeeignete Datenelemente' 
ausgeschlossen. 

Natürlich müßte es weiterhin möglich sein, die Datenelemente zu höheren 


Strukturen zu kombinieren. Diese Kombinationsmöglichkeiten dürfen gegen- 
über dem klassischen Pascal nicht eingeschränkt sein. 
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3.2 Ein erstes Beispiel 


Betrachten wir als erstes Beispiel das angesprochene Klassifikationsproblem. 
Normalerweise würde man etwa folgendes codieren: 


program Beispiel]; 


var Temp1, Temp2 : integer; 
Income1, Income2 : longint; 


procedure ClassifyTemp( Temp : integer ); 


begin 
if Temp < -10 then 
Writeln( 'wahrscheinlich Winter’ ) 
else 
if Temp > 25 then 
Writeln( 'wahrscheinlich Sommer’ ) 
else 
Writeln( "keine Aussage möglich’ ); 
end; (-- ClassifyTemp } 


procedure ClassifyIncome( Income : longint ); 


begin 
if Income < 20000 then 
Writeln( 'Sozialfall’ ) 
else 
if Income > 100000 then 
Writeln( 'Unsozialer Fall’ ) 
else 
Writeln( ’Normalfall’ ); 
end; {-- ClassifyIncome } 


begin 

end. 

Im Programm könnte man dann z.B. schreiben: 
ClassifyTemp( Temp1 ); oder 
ClassifyInc( 30000 ); 

Niemand hindert uns jedoch daran, 
ClassifyTemp( 30000 ); 


zu schreiben. Auch hier würde ein Programmierer den Fehler wohl sofort an 
den nicht zusammenpassenden Größen erkennen, normalerweise sind solche 
Fälle aber wesentlich diffiziler, insbesondere wenn man ein größeres Pro- 
gramm nach längerer Pause modifizieren muß. 


Unter Verwendung von Objekten könnte man das gleiche Problem etwa wie 
folgt notieren: 
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program Beispiel2; 


type Temp = object 
Value : integer; 
procedure Classify; 
end; {-- Temp } 

type Income =. object 
Value : longint; 


procedure Classify; 
end: (-- Income } 


procedure Temp.Classify; 


begin 
if Value < -10 then 
Writeln( "wahrscheinlich Winter’ ) 
else 
if Value > 25 then 
Writeln( 'wahrscheinlich Sommer’ ) 
else 
Writeln( ’keine Aussage möglich’ ); 
end; (-- Classify )} 


procedure Income.Classify; 


begin 
if Value < 20000 then 
Writeln( 'Sozialfall’ ) 
else 
if Value > 100000 then 
Writeln( 'Unsozialer Fall’ ) 
else 
Writeln( ’Normalfall’ ); 
end; {-- Classify ) 


begin 
end. 


Vergleicht man die konventionelle mit der objektorientierten Lösung, er- 
kennt man folgende Unterschiede: 


- Die Deklaration eines Objekts ähnelt der eines klassischen Records. Zu- 
sammengehörige Elemente werden hier durch die Schlüsselworte object 
und end eingeklammert. 


- Die Objektdeklaration enthält neben einem Datenelement (integer) auch 
ein Verarbeitungselement (procedure). 


- Für die Implementierung der beiden classify-Prozeduren wird die bisher 
nur für Daten definierte Punktnotation verwendet. 


- Die beiden classify-Prozeduren haben keine Parameter. Trotzdem 
können sie auf das jeweilige Datenelement value zugreifen. Der 
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Compiler stellt sicher, daß dabei das zum eigenen Objekt gehörige 
Datenelement verwendet wird. 


- Die Objekte sind als Typen deklariert. 


Ausgerüstet mit diesen Deklarationen kann man z.B. schreiben: 


var T1, T2 : Temp; 
I : Income; 


und später im Programm z.B. 


T1.Classify; 
oder 


l.Classify; 


Durch das Fehlen von Parametern werden (zumindest an dieser Stelle) Miß- 
verständnisse vermieden. In T1.Classify wird die Prozedur Temp.Classify auf- 
gerufen, die Variable value ist dabei natürlich Temp.value. Analoges gilt für 
l.Classify. 


Die Implementierung dieses einfachen Beispiels mit Mitteln der objektorien- 
tierten Programmierung zeigt deutlich die stärkere Bindung von Daten und. 
Algorithmen gegenüber der konventionellen Implementierung. Dies wird er- 
kauft durch einen etwas längeren Quelltext, die Größe der ausführbaren Da- 
tei steigt jedoch nicht. Dieses auf den ersten Blick erstaunliche Ergebnis 
rührt daher, daß die objektorientierte Implementierung des Beispiels genau 
der konventionellen Implementierung entspricht. Es ist keine neue Funktio- 
nalität hinzugekommen: In beiden Fällen sind Datenelemente und Verarbei- 
tung gleich - nur eben unterschiedlich formuliert. 


3.3 Zur Sprache 


Es gibt einige Bgriffe, die in der objektorientierten Programmierung immer 
wieder auftauchen. So werden z.B. die Prozeduren und Funktionen eines 
Objekts allgemein als Methoden bezeichnet. Man spricht auch nicht mehr von 
der Deklaration eines Objekttyps, sondern vielmehr einfach von der Dekla- 
ration eines Objekts. Daß es sich hierbei um eine Typvereinbarung handelt, 
ist klar, denn Objekte können nicht direkt als Variable deklariert werden. 
Deklariert man dagegen Variablen eines Objekts, nennt man dies eine /nstanz 
dieses Objekts erzeugen. Dieser Ausdruck stammt aus der dynamischen Spei- 
cherverwaltung; auch im klassischen Pascal kann man ja mit new eine Instanz 
einer Variablen erzeugen. Wie wir sehen werden, kann man Objekte ebenso 
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dynamisch erzeugen und verwalten wie gewöhnliche Variablen. Die Aus- 
drücke Instanz und Instanzieren haben sich für Objekte generell eingebürgert 
und werden auch für Deklarationen mit var verwendet. 
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4 Ein kleines Fenstersystem 


4.1 Aufgabenstellung 


Wir wollen im folgenden ein etwas größeres Problem mit Techniken der ob- 
jektorientierten Programmierung implementieren. Am Beispiel eines einfa- 
chen Fenstersystems sollen objektorientierte Techniken aufgezeigt werden. 
Laufzeit- und Speicherplatzfragen stehen dabei zunächst im Hintergrund; 
ebenso ist z.B. die Funktionalität wohl kaum ausreichend, um das Programm 
z.B. als Tool verkaufen zu können. 


Das wird hier zunächst in einer sehr einfachen Version entwickelt. Diese 
wird in den nächsten Kapiteln ausgebaut und erweitert. Dabei kommen 
immer mehr objektorientierte Techniken zum Einsatz. Am Schluß steht ein 
System, das als Ausgangsbasis für eine wirklich professionelle Pro- 
grammierung stehen kann. 


Das Fenstersystem soll rechteckige Bereiche zur Ausgabe von Texten auf 
dem Bildschirm definieren können. Der vor dem Öffnen des Fensters vor- 
handene Bildschirminhalt an der Position des Rechtecks soll wiederherge- 
stellt werden können. Die Fenster sollen in ihrer Größe verändert und auf 
dem Bildschirm verschoben werden können. 


4.2 Implementierung 


Wir werden ein Objekt deklarieren, das neben den erforderlichen Daten auch 
Prozeduren zum Einrichten, Manipulieren und Löschen eines Fensters bein- 
haltet. Für jedes Fenster auf dem Bildschirm ist dann eine Instanz dieses 
Objektes erforderlich. 


Bei der Definition eines Fensters greifen wir auf die Turbo-Pascal Prozedur 
Window zurück, die es erlaubt, alle Bildschirmoperationen auf einen rechtecki- 
gen Bereich auf dem Bildschirm zu begrenzen. Ergänzt man diesen Bereich 
um einen Rahmen, erhält man schon ein brauchbares Fenster. 
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Es gibt jedoch keine Prozedur, um ein solches Fenster wieder zu schließen. 
Dazu muß der ursprüngliche Bildschirminhalt an der Stelle des Fensters wie- 
derhergestellt werden. Dies geht natürlich nur, wenn er vor dem Öffnen ge- 
sichert wurde. Da diese Sicherung für jedes Fenster erneut erforderlich ist, 
verwenden wir hierfür eine Variable im Objekt. 


Die Bildschirmausgabe stellt wohl in keiner Sprache ein Problem dar. Zum 
Einlesen von Bildschirminhalten in Variable ist jedoch keine Möglichkeit 
vorhanden. Dazu ist der direkte Zugriff auf den Bildschirmspeicher des 
Rechners erforderlich. 


4.3 Die Bildschirmhardware 


In IBM-kompatiblen PCs können eine Reihe von verschiedenen Bildschirm- 
adaptern eingesetzt werden. Die gebräuchlichsten sind Hercules, CGA und 
neuerdings auch EGA und VGA Adapter. Sie sind alle "memory mapped", 
d.h. der Bildspeicher ist irgendwo im Hauptspeicher des Rechners angeord- 
net. Für jedes Zeichen auf dem Bildschirm werden dabei zwei Byte verwen- 
det: eines für das Zeichen selber und eins für das Attribut des Zeichens. Das 
Attributbyte enthält die Farbe des Zeichens sowie andere Informationen. Die 
Kenntnis dieser Codierung ist für die gestellte Aufgabe nicht erforderlich, da 
wir die Zeichen ja nur speichern und später ohne Anderung wieder zurück- 
kopieren wollen. 


Unglücklicherweise ist die Startadresse des Bildschirmspeicherbereiches 
nicht für alle Bildschirmadapter gleich. Beschränkt man sich auf den norma- 
len 25x80 Zeichen-modus, kommen noch die beiden Adressen $8800:0 und 
$8000:0 in Frage. 


4.4 Die Objektdeklaration 


Wir benötigen also eine Variable zur Aufnahme des zwischenzuspeichernden 
Bildschirminhaltes sowie eigene Prozeduren zum Öffnen und Schließen des 
Fensters. Variable und Prozeduren werden zum Objekt wndr 
zusammengefaßt: 


type WndT = object 
Buffer : array[ 1..25*80*2 ] of char; 


procedure Open( XMin, YMin, XMax, YMax : integer ); 
procedure Close; 


end; {-- WndT } 
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Die beiden Prozeduren open und close in der Objektdeklaration definieren die 
Methoden des Objekts. Obwohl in der objektorientierten Programmierung 
von Methoden gesprochen wird, schreibt man in Turbo-Pascal traditionell 
procedure und function. 


Daten- und Methodendefinition können nicht gemischt werden. Zuerst müs- 
sen alle Datenelemente, dann alle Methoden definiert werden. 


4.5 Die Objektimplementierung 


Die Methoden in der Objektdeklaration haben die Wirkung einer Forward-De- 
klaration, d.h. sie müssen weiter unten im Programmtext implementiert wer- 
den. Der Implementierungsteil muß nicht sofort auf den Deklarationsteil fol- 
gen, sondern zwischen beiden Teilen können weitere Deklarationen oder 
Prozedurimplementierungen stehen. 


Die Implementierung der beiden Methoden könnte etwa folgendermaßen aus- 
sehen: 


procedure WndT.Open( XMin, YMin, XMax, YMax : integer ) 

var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 

ScreenBase:= GetScreenBase; 

Move( ptr( ScreenBase, 0 )”“, Buffer, 25*80%2 ); 

Window( XMin, YMin, XMax, YMax ); 

end; {-- Open } 


procedure WndT.Close; 


var ScreenBase : word; (-- Segmentaddr. Bildschirmspeicher } 
begin 
ScreenBase:= GetScreenBase; 


Window( 1, 1, 80, 25 ); 
Move( Buffer, ptr( ScreenBase, 0 )”, 25*80*2 ); 


end; {-- Close } 


Im Implementierungsteil müssen die Methoden mit vollem Namen, also mit 
vorangestelltem Objektbezeichner, angegeben werden. Dies ist erforderlich, 
da mehrere Objekte z.B. eine Prozedur close definieren können. Außerdem 
wäre es sonst nicht möglich, eine "normale" Prozedur mit dem Namen Close 
zu definieren. 
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Analog zur konventionellen Forward-Definition kann bei der Implementierung 
der Prozedur die Parameterliste auch weggelassen werden. Man könnte also 
statt 


procedure WndT.Open( XMin, YMin, XMax, YMax : integer ); 
auch einfach 
procedure WndT.Open; 


schreiben. Wenn die Objekte größer werden, ist diese Form nicht mehr zu 
empfehlen, denn die Formalparameter der Parameterliste können ja gleich- 
zeitig auch Deklarationen lokaler Variablen sein. Die Vereinbarung lokaler 
Variablen gehört aber sicherlich zum Implementierungsteil einer Prozedur. 
Deshalb ist es mehr als nur guter Stil, die Parameterliste im Implementie- 
rungsteil zu wiederholen. 


Die Funktion GetscreenBase liefert die Segmentadresse des Bildschirmspei- 
chers zurück. Zur vollständigen Adresse fehlt dann noch der Offset-Teil, der 
hier immer 0 ist, da der Bildschirmspeicher grundsätzlich an einer Segment- 
grenze beginnt. Das Konstrukt ptrc ScreenBase, 0 ) ist also ein Zeiger auf die 
Anfangsadresse des Bildschirmspeichers des jeweiligen Bildschirmadapters. 


function GetScreenBase : word; 


liefert die Segmentadresse des Bildschirmspeichers 
} 


var R : Registers; 


begin 

Intrc $11, R ); (-- BIOS EquipmentList } 

if R.AX and $30 = $30 then {-- Monochromadapter } 
GetScreenBase:= $BO00 

else 
GetScreenBase:= $B800; 

end; {-- GetScreenBase } 


Die Anordnung der Prozedur im Programmtext ist unkritisch, wir haben Sie 
zur Demonstration zwischen Objektdeklaration und -Implementierung pla- 
ziert. Wegen ihrer allgemeinen Verwendbarkeit werden wir sie später in eine 
Unit mit allgemeinen Hilfsprozeduren verlegen. 


Um den ersten Entwurf des Fenstersystems zu testen, verwenden wir folgen- 
des Hauptprogramm, das ein Fenster der Größe 15x10 erzeugt und dieses mit 
zufälligen Buchstaben füllt: 
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var W : WndT; 


begin 
ClrScr; 


W.Open( 10, 10, 25, 20 ); 
while not Keypressed do 
begin 
Delay( 50 ); 
Write( char( Random( 26 ) + 65 ) ); 
end; 


W.Close; 


end. 


Im diesem Programm ist w kein Objekt, sondern eine Instanz eines Objekts. 
Durch die Zeile var w : wndt wird eine Instanz des Objekts wndt erzeugt. 


4.6 Die with-Anweisung 


Ähnlich wie bei Records ist auch für Objekte die Verwendung der with-An- 
weisung möglich. Die Anwendung ist in diesem Beispiel nicht besonders 
sinnvoll, da die beiden einzelnen Anweisungen w.open und w.close relativ weit 
auseinanderstehen. Es wird hier nichts an Klarheit gewonnen, das folgende 
Programm dient lediglich zur Demonstration: 


var W : WndT; 


begin 
ClrScr; 


with W do 

begin 

Open( 10, 10, 25, 20 ); 

while not Keypressed do 
begin 
Delay( 50 ); 
WriteC char( Random( 26 ) + 65 ) ); 
end; 
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4.7 Zuweisung von Objekten 


Hat man mehrere Variable eines Objekttyps deklariert, sind damit bereits 
mehrere Instanzen eines Objekts erzeugt. Bei der Zuweisung einer Instanz an 
eine Variable wird daher lediglich der Datenbereich kopiert. Es wird keine 
neue Instanz erzeugt! 


Die obige Definition von wndt vorausgesetzt, kann man z.B. folgende Zuwei- 
sung vornehmen: 


var W1, W2 : WndT; 


begin 
Cirscr; 


wW1.Open( 10, 10, 25, 20 ); 
W2:= W1; 


Nun kann man zum Schließen des Fensters sowohl w1.close als auch w2.Close 
aufrufen. In diesem Beispiel ist es nicht tragisch, wenn versehentlich beide 
Instanzen geschlossen werden. Das liegt unter anderem daran, daß das Bei- 
spiel so einfach wie möglich gehalten wurde. Wenn z.B. das Fenstersystem 
dahingehend erweitert wird, daß close vorher belegten Speicher auf dem 
Heap wieder freigibt, führt eine zweimalige Freigabe desselben Speicherbe- 
reiches zu einem undefinierten Zustand des Heap. Nicht immer wird dabei 
eine Fehlermeldung vom Laufzeitsystem erzeugt! 


4.8 Objekte als Parameter für Prozeduren 
und Funktionen 


Instanzen können wie normale Variable als var- oder value-Parameter an Pro- 
zeduren und Funktionen übergeben werden. Bei der Übergabe als var-Para- 
meter wird ein Zeiger auf die Instanz übergeben, so daß diese Instanz inner- 
halb der Prozedur bearbeitet werden kann. 


Bei der Übergabe als vatue-Parameter wird eine Kopie der Instanz übergeben. 
Diese lokale Kopie existiert nur innerhalb der Prozedur, Änderungen wirken 
sich auf die Originalinstanz nicht aus. Dieser Mechanismus ist analog zur be- 
kannten Variablenübergabe im klassischen Pascal. 


Im folgenden Beispiel wird eine Instanz als value-Parameter übergeben. Nur 
diese lokale Kopie wird gelöscht, das Original bleibt erhalten. 
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procedure Delete( LocalW : WndT ); 
begin 
with LocalW do 
FillChar( Buffer, SizeOf( Buffer ), #0 ); 
end; {-- Delete )} 


Am einfachsten stellt man sich ein Objekt zum Zweck der Parameterübergabe 
als record vor. Im obigen Beispiel wäre das also 


type WndT = record 
Buffer : array[ 1..25*80%2 ] of char; 
end; {-- WndT } 


4.9 Objektkonstanten 


Genauso wie typisierte Konstanten (die ja eigentlich initialisierte Variablen 
sind) können Objektkonstanten definiert werden. Die Objektdeklaration kann 
man sich hier wiederum als record-Vereinbarung vorstellen. 


Das folgende Objekt kann zur Repräsentation einer komplexen Zahl verwen- 
det werden. Als Beispiel einer Operation mit komplexen Zahlen soll die 
Addition implementiert werden. 


type ComplexT = object 
XReal, Xlmg : real; 


procedure Add( var Value : ComplexT ); 
procedure Print; 


end; {-- ComplexT } 
procedure ComplexT.Add( var Value : ComplexT ); 
begin 


XReal:= XReal + Value.XReal; 
XImg := XImg + Value.XlImg; 


end; {-- Add } 
procedure ComplexT.Print; 


begin 
Writelnt 'C’, XReal, '/', Xlmg, ')’ ); 
end; {-- Print ) 


var V1 : ComplexT; 


( XReal : 2; XlImg : 


const C1 : ComplexT 5 
( XReal : 4; XImg : 7 


C2 : ComplexT 


); 
); 
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begin 
Write( 'C1 : ' Js; C1.Print; 
Write( 'C2 : ' ); C2.Print; 


C2.Add( C1 ); 
Writel 'C1 + C2 : ' ); C2.Print; 


end. 


4.10 Dynamische Objekte 


Bis jetzt haben wir Instanzen von wndr mit der var-Anweisung im Datenseg- 
ment erzeugt. Mit den bekannten Anweisungen new DZw. Getmem können Ob- 
jekte auch auf dem Heap angelegt werden. Dies bezieht sich natürlich nur auf 
die Daten des Objektes; der Code für die Methoden landet weiterhin im Co- 
desegment. Die Vorgehensweise bei der dynamischen Verwaltung von Ob- 
jekten ist dabei analog zur konventionellen dynamischen Speicherverwal- 
tung: 


var W1, W2, W3 : "WndT; 
begin 


New( W1 ); 
W1*.Open( 10, 10, 25, 20 ); 
while not Keypressed2 do 
Write(C char( Random( 26 ) + 65 ) ); {-- Buchstaben } 


New( W2 ); 
wW2“.Open( 13, 13, 28, 23 ); 
while not Keypressed2 do 
WriteC char( Random( 10 ) + 48 ) ); {--- Zahlen } 


New W3 ); 
W3*.Open( 5, 14, 16, 16 ); 
while not Keypressed2 do 
Write( char( Random( 14 ) + 33 ) ); (--- einige Sonderzeichen } 


W3”“.Close; Dispose( W3 ); 
W2”.Close; Dispose( W2 ); 
W1*.Close; Dispose( W1 ); 


end. 
Etwas gewöhnungsbedürftig ist nur die Notation der Methodenaufrufe, für 


die jetzt natürlich auch Zeiger verwendet werden müssen. Dies hat aber 
nichts mit Prozedurvariablen zu tun! 
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Die Prozedur Keypressed2 ist eine weitere Hilfsprozedur, die genau wie 
Keypressed TRUE zurückliefert, wenn eine Taste gedrückt wurde. Zusätzlich 
wird dieses Zeichen aus dem Tastaturpuffer entfernt, da nachfolgende Auf- 
rufe von Keypressed sonst immer TRUE liefern würden. 


Eine Implementierungsmöglichkeit zeigt das folgende Listing: 
function Keypressed2 : boolean; 
var C : char; 


begin 
if Keypressed then 
begin 
KeyPressed2:= true; 
C:= Readkey; 
end 
else 
KeyPressed2:= false; 
end; {-- KeyPressed2 } 


Die Zuweisung von Objekt-Zeigervariablen ist problemlos möglich. Man 
kann z.B. folgendes codieren: 


var W1, W2 : "WndT; 
begin 


New( W1 ); 
W1*.Open( 10, 10, 25, 20 ); 
while not Keypressed2 do 
Write( char( Random( 26 ) + 65 ) ); (-- Buchstaben } 


Ww2:= W1; 
W2”.Close; Dispose( W2 ); 
end. 


Hier wird keine Kopie des Objekts erzeugt, sondern wı und w2 zeigen in der 
aus der konventionellen Programmierung bekannten Weise auf das gleiche 
Objekt. 


Sollte hier irrtümlich später zusätzlich w1*.close aufgerufen werden, hat dies 
nicht notwendigerweise so fatale Folgen wie im weiter oben dargestellten 
Falle der Duplizierung von Objekten bei der direkten Zuweisung. Close kann 
nämlich so erweitert werden, daß beim Schließen z.B. eine Statusvariable 
entsprechend gesetzt wird. Ein doppeltes Schließen der gleichen Instanz kann 
so erkannt werden. 
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4.11 Erweiterung auf mehrere Fenster 


Die Erweiterung des kleinen Fensterprogramms auf mehrere Fenster bereitet 
keine Schwierigkeiten. Es werden einfach mehrere Instanzen von wndT er- 
zeugt, deren open-Methoden nacheinander aufgerufen werden, etwa wie im 
folgenden Hauptptrogramm: 


var W1, W2, W3 : WndT; 


begin 
ClrScr; 


W1.Open( 10, 10, 25, 20 ); 
while not Keypressed2 do 
Write( char( Random( 26 ) + 65 ) ); (-- Buchstaben } 


W2.Open( 13, 13, 28, 23 ); 
while not Keypressed2 do 
WriteC char( Random( 10 ) + 48 ) ); (--- Zahlen } 


W3.Open( 5, 14, 16, 16 ); 
while not Keypressed2 do 
WriteC char( Random( 14 ) + 33 ) ); (--- einige Sonderzeichen } 


W3.Close; 
W2.Close; 
W1.Close; 


end. 


Da im Hauptprogramm drei Instanzen für wndr erzeugt werden, reserviert der 
Compiler Speicherplatz für drei Buffer-Variablen. Der Code für die beiden 
Methoden wird jedoch nur einmal aufgenommen. 


Beachten Sie bitte, daß die Fenster in umgekehrter Reihenfolge wieder ge- 
schlossen werden. Eigentlich würde ja der Aufruf von w1.close ausreichen, da 
dadurch der gesamte Bildschirminhalt wiederhergestellt würde. Das wäre 
schlechter Programmierstil, denn wir gehen dabei von Wissen über die in- 
terne Implementierung von wndt aus, die uns als Nutzer des Objekts nicht in- 
teressieren sollte. Was wäre, wenn die nächste Version des Fenstersystems 
aus Speicherplatzgründen nur den tatsächlich verwendeten Bildschirm- 
speicherbereich sichert? 


Nicht immer sind die Folgen so klar und ungefährlich wie hier. Als Pro- 
grammierer eines größeren Systems kann man sich sicherlich schnell genü- 
gend abschreckende Beispiele für solche Nebeneffekte ausdenken. 


Erreicht das Programm die Anweisung w2.open, muß zur Prozedur wndT.open 
verzweigt werden. Dies stellt für den Compiler kein Problem dar, da w2 eine 
Instanz von wndr ist und daher nur wndt.open in Frage kommt. 


24 4 Ein kleines Fenstersystem 


WndT.Open hat jedoch keine Parameter. Im Quelltext der Prozedur steht aber 
eine Referenz auf Buffer, und zur Übersetzungszeit der Methode ist noch 
nicht bekannt, ob es sich dabei um w1.Buffer oder eine beliebige andere In- 
stanz von wndt handelt. Dieses Problem lösen objektorientierte Programmier- 
sprachen durch einen implizit übergebenen, versteckten Parameter. 


4.12 Der Self-Parameter 


Bei der Übersetzung von wndT.open trifft der Compiler auf eine Referenz auf 
Buffer. Welche Adresse soll für Buffer verwendet werden? Bei der Objektde- 
klaration ist noch kein Speicher zugewiesen worden, da dies erst bei der Er- 
zeugung einer aktuellen Instanz geschieht . 


Das Problem wird mit Hilfe eine versteckten Parameters gelöst. Die Para- 
meterliste von wndt.open wird dabei vom Compiler automatisch um einen zu- 
sätzlichen Parameter ergänzt, der beim Aufruf mit der Startadresse der Ob- 
jektinstanz besetzt wird. Technisch wird dazu ein gewöhnlicher Zeiger ver- 
wendet, von der Syntax her wird er als var-Parameter vom entsprechenden 
Objekttyp notiert. 


Der Parameter hat den festen Namen setf und wird als letzter Wert in die Pa- 
rameterliste eingefügt. Der Compiler codiert für undt.open also 


procedure WndT.Open( XMin, YMin, XMax, YMax : integer; var Self : WndT ); 
und entsprechend im Prozedurtext 
with Self do 
begin 
< Eigentlicher Prozedurtext> 
end; 
Beim Aufruf der Methode wird dann im Hauptprogramm die aktuelle Instanz 
hinzugefügt: 
W1.Open( 10, 10, 25, 20, W1 ); 


W2.Opent 13, 13, 28, 23, W2 ); 
W3.Open( 5, 14, 16, 16, W3 ); 


Beachten Sie bitte, daß diese Beispiele nur zur Demonstration der impliziten 
Parameterübergabe dienen. Obwohl es natürlich möglich ist, Objekte als Pa- 
rameter zu übergeben, würde der Compiler in diesen Fällen die Fehlermel- 
dung Duplicate Identifier ausgeben, da sei f ein vordefinierter Bezeichner ist. 
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self kann andererseits vom Programmierer explizit verwendet werden, z.B. 
um Mehrdeutigkeiten aufzulösen. Im folgenden Beispiel wird ein Objekt vom 
eigenen Objekttyp als Parameter übergeben: 


type ComplexT = object 
XReal, XiImg : real; 
function IsEqual( var CompareNwmber : ComplexT ) : boolean; 
end; (-- ComplexT } 
function ComplexT.IsEqual( var CompareNumber : ComplexT ) : boolean; 
begin 
with Comparenumber do 


IsEqual:= ( Self.XReal = XReal ) and ( Self.XImg = XImg ); 
end; {-- IsEqual } 


Die ohne Verwendung von self entstehende Mehrdeutigkeit könnte man nur 
durch Verzicht auf die (bequeme) with-Anweisung auflösen: 

function ComplexT.IsEqual( var CompareNumber : ComplexT ) : boolean; 

begin 


IsEqual:= ( CompareNumber.XReal = XReal ) and ( CompareNumber.XImg = XImg ); 
end; {-- IsEqual } 


Die Objektvariablen sind mit Hilfe dieses Mechanismus automatisch in allen 
Methoden des Objekts sichtbar. Sie können aber nicht (wie globale Variablen 
etwa) in einer Methode redefiniert werden. Daraus folgt, daß die Formalpa- 
rameter sowie die lokalen Variablen einer Methode nicht den gleichen Na- 
men wie ein Datenelement des Objekts haben können. 


Die folgenden beiden Konstruktionen sind aus diesem Grunde unzulässig: 
type ComplexT = object 

XReal, XlImg : real; 

procedure SetValue( XReal, XImg : real ); 

end; {-- ComplexTT } 


procedure ComplexT.SetValue( XReal, XImg : real ); 


begin 
Self.XReal:= XReal; 
Self.XImg := XlImg; 


end; {-- SetValue } 
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type ComplexT = object 
XReal, XlImg : real; 
procedure SetValue( NewXReal, NewXImg : real ); 


end; {-- ComplexTT } 


procedure ComplexT.SetValue( NewXReal, NewXImg : real ); 
var Xreal, XlImg : real; 


begin 
end; {-- SetValue } 


In beiden Fällen erhält man die Fehlermeldung pupt icate Identifier, wenn der 
Compiler die Implementierung der Methode erreicht. 


4.13 Der Übersetzungsvorgang 


Um ein besseres Verständnis der Unterschiede zwischen objektorientiertem 
und konventionellem Ansatz zu gewinnen, kann man sich überlegen, was bei 
der Übersetzung von Objektdefinition, Implementierung und Hauptpro- 
gramm passiert. 


Wir verwenden als Demonstrationsobjekt die Objektdefinition aus Abschnitt 
4.4 zusammen mit der zugehörigen Implementierung aus Abschnitt 4.5. Wird 
die Übersetzung dieses Programms gestartet, sieht der Compiler zuerst die 
Objektdefinition. Die Datenelemente werden wie ein gewöhnlicher record be- 
handelt, in unserem Falle also 


type WndT = record 

Buffer : arrayl[l 1..25*80*2 ] of char; 

end; {-- WndT } 
Die folgenden Methodendeklarationen werden als Forward-Deklarationen in- 
terpretiert, allerdings wird der Objektname vorangestellt. Abgesehen von der 


für Prozeduren im klassischen Pascal nicht möglichen Punktnotation wäre 
dies in unserem Fall analog zu 


procedure WndT.Open( XMin, YMin, XMax, YMax : integer ); forward; 
procedure WndT.Close; forward; 


Als nächstes folgt die Implementierung der Methoden. Die Prozeduren müs- 
sen dort mit vollständigem Namen (also incl. Objektnamen) angegeben wer- 
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den. Sie entsprechen daher genau den im Definitionsteil spezifizierten zuge- 
hörigen Forward-Deklarationen. 


Genaugenommen wird in der Forward-Deklaration und in der Implementierung 
noch der sei f-Parameter eingefügt. Wichtig ist, daß der seıf-Parameter zwar 
in der Parameterliste nicht in Erscheinung tritt, vom Compiler aber wie eine 
normale Variable verwaltet wird. setf wird automatisch deklariert, und zwar 
mit dem Typ des jeweiligen Objekts. 


In unserem Fall wurde seıf also analog zur Anweisung 


var Self : WndT; 


deklariert. Beachten Sie, daß wndr früher in der Übersetzung als record inter- 
pretiert wurde. Bevor mit der Übersetzung der eigentlichen Methode begon- 
nen wird, fügt der Compiler noch die Anweisung 


with Self do 


ein. Trifft der Compiler nun auf eine Referenz eines Datenelements des Ob- 
jekts, kann diese Referenz dank der intern generierten with-Anweisung pro- 
blemlos aufgelöst werden. 


Da für die interne Definition von self wndr als gewöhnlicher record interpre- 
tiert wurde, können Methoden nicht so einfach referenziert werden. Sie müs- 
sen grundsätzlich mit vollständigem Namen (also mit vorangestelltem Ob- 
jektnamen) referenziert werden. 


Während der Übersetzung der Objektdefinition wurden die Datenelemente zu 
einem record zusammengefaßt. Die Instanzierung eines Objekts kann deshalb 
vollständig auf die Deklaration eben diesen Typs zurückgeführt werden. 
Schreibt man also 


var W : WndT; 


interpretiert der Compiler undr in dieser Zeile als 
type WndT = record 
Buffer : array[ 1..25%80%2 ] of char; 


end; {-- WndT } 


Analog wird die Instanzierung mit new oder GetMem auf dem Heap bzw. einer 
lokalen Instanz auf dem Stack durchgeführt. 


Durch die interne Definition als record kann man überall im Programm auf 
die Datenelemente des Objekts mit der gewohnten Punktnotation zugreifen. 
Ebenso kann die Definition von Objektkonstanten einfach auf die Definition 
typisierter Konstanten zurückgeführt werden. 
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Eine Referenz einer Methode (entweder im Hauptprogramm oder im Imple- 
mentierungsteil einer (anderen) Methode) enthält immer zwei Teile: eine 
Objektreferenz vor dem Punkt und eine Methodenreferenz. Die Anweisung 
W1.openc...) wird folgendermaßen aufgelöst: Zuerst wird die Objektreferenz 
extrahiert. In diesem Beispiel ist wı eine Instanz, die auf das zugehörige Ob- 
jekt wndt zurückgeführt wird. Das Ergebnis, wndt.openc...) kann sofort zuge- 
ordnet werden, da eine Prozedur genau diesen Namens schon übersetzt 
wurde. 


Dieser Abschnitt zeigt, daß die bis jetzt eingeführten objektorientierten 
Sprachmittel sich recht einfach auf bestehende Sprachmittel zurückführen 
lassen. Technisch gesehen handelt es sich im wesentlichen um die Einfüh- 
rung des self Parameters und der impliziten witn-Anweisung sowie - was die 
Daten betrifft - die Interpretation als gewöhnlicher record. 


4.14 Vergleich mit konventioneller 
Implementierung 


Das Fenstersystem in seiner jetzigen Form kann problemlos mit konventio- 
nellen Sprachmitteln realisiert werden. Folgende Implementierung liegt nahe: 


type BufferT = array[ 1..25*80*2 ] of char; 

procedure Open( XMin, YMin, XMax, YMax : integer; var Buffer : BufferT ); 
var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 

ScreenBase:= GetScreenBase; 

Move( ptr( ScreenBase, 0 )”, Buffer, 25*80*2 ); 

Window XMin, YMin, XMax, YMax ); 

end; {-- Open } 


procedure Close( Var Buffer : BufferT ); 


var ScreenBase : word; (-- Segmentaddr. Bildschirmspeicher } 
begin 
ScreenBase:= GetScreenBase; 


Window 1, 1, 80, 25 ); 
Move( Buffer, ptr( ScreenBase, 0 )*, 25*80*2 ); 


end; {-- Close } 
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var Bil, B2, B3 : BufferT; 


begin 
ClrScr; 
Open( 10, 10, 25, 20, B1 ); 


while not Keypressed2 do 
WriteC char( Random( 26 ) + 65 ) ); (-- Buchstaben } 


Open( 13, 13, 28, 23, B2 ); 
while not Keypressed2 do 
WriteC char( Random( 10 ) + 48 ) ); (--- Zahlen ) 


Open( 5, 14, 16, 16, B3 ); 
while not Keypressed2 do 
WriteC char( Random( 14 ) + 33 ) ); (--- einige Sonderzeichen } 


Close( B1 ); 
Close( B2 ); 
Close( B3 ); 


end. 


Zweifelsohne sehen konventionelle und objektorientierte Implementierung 
sehr ähnlich aus. Vergegenwärtigt man sich noch das über die implizite Pa- 
rameterübergabe Gesagte, sind eigentlich keine Unterschiede mehr zu sehen. 
Die Übergabe von Buffer muß eben in konventionellem Pascal manuell co- 
diert werden, aber das ist dann schon alles. 


Ist es wirklich schon alles? In diesem Beispiel ja, und vor allem, wenn man 
die beiden Implementierungen unter technischen Gesichtspunkten sieht, wie 
wir das bis jetzt getan haben. Aus Anwendersicht (und das ist hier der Pro- 
grammierer) sieht die Sache anders aus. 


Beim Entwurf des Fenstersystems haben wir festgestellt, daß wir eine Va- 
riable zur Zwischenspeicherung des Bildschirminhalts sowie eine Prozedur 
zur Durchführung der Speicherung benötigen. Es ist klar, daß die Prozedur 
auf diese Variable zugreifen muß. Warum also die Variable als Parameter 
übergeben, wenn schon beim Programmdesign klar ist, daß die Prozedur die 
Variable immer braucht? 


Mit objektorientierter Programmierung drücken wir genau diesen Zusam- ; 
menhang durch die Klammerung von Datenelementen und Verarbeitungs- 
schritten zwischen den Schlüsselworten object und end aus. Über den seıf-Pa-! 
rameter stehen die Daten nun den Prozeduren (und nur diesen) ohne explizite 
Übergabe zur Verfügung. 


Weiterhin sollten Variablen vom Typ Buffer dem Anwender nicht zugänglich 
sein, da sich die mit diesen Daten erlaubten Operationen auf den Aufruf von 
Open und Close beschränken. In der konventionellen Implementierung müssen 
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die Puffer global deklariert werden, da die Arbeitsprozeduren sonst nicht 
darauf zugreifen können. Sie stehen damit prinzipiell aber auch anderen Pro- 
zeduren zur Verfügung. Damit entsteht eine nicht zu unterschätzende Fehler- 
quelle bei der Programmentwicklung, wie das Beispiel mit Temp und Income 
aus Kapitel 3 zeigt. 


In der objektorientierten Programmierung wird Buffer innerhalb des Objekts 
versteckt und sollte dem Anwender nicht direkt zur Verfügung stehen. Der 
Konjunktiv im letzten Satz ist (leider?) erforderlich, denn in Turbo-Pascal ist 
der direkte Zugriff auf objektinterne Daten ohne weiteres möglich. Turbo- 
Pascal ist in diesem Sinne keine "reine" objektorientierte Programmierspra- 
che wie z.B. Smalltalk. Die Möglichkeit zum direkten Zugriff findet sich 
nicht nur in Turbo-Pascal, sondern in allen gängigen objektorientierten Pro- 
grammiersprachen, also auch z.B. in Pascal:QuickQuick-Pascal, C++ und 
Objective-C. Dies hat einen sehr praktischen Grund: Ohne die "direkte 
Zugriffsmöglichkeit wäre man gezwungen, für tatsächlich jeden denkbaren 
Zugriff auf Objektdaten eine Methode zu definieren. 


Aus theoretischer Sicht ist so etwas sicherlich wünschenswert, für den prak- 
tischen Einsatz aber ungeeignet. Es soll dem Programmierer überlassen blei- 
ben, für welche Zugriffe er Methoden definiert bzw. wo er besser direkt zu- 
greift. 


Diese Argumentation ist noch nicht vollständig. Wesentliche Ziele objektori- 
entierter Programmierung sind Erweiterbarkeit und Wiederverwendbarkeit 
einmal entwickelter Programmteile. Man muß dazu verstehen, wie bereits 
vorhandene Objekte zur Definition weiterer Objekte herangezogen werden 
können. Hierüber erfahren Sie alles im nächsten Kapitel. 
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5 Vererbung 


5.1 Begriffsdefinitionen 


Einmal vorhandene Objekte können zur Definition weiterer Objekte herange- 
zogen werden. Das Objekt, das zur Definition verwendet wird, heißt Vor- 
gänger- oder Vaterobjekt. Das neue Objekt wird abgeleitetes Objekt oder 
Nachkomme genannt. Bei dieser Art von Objektdefinition, auch Ableitung 
genannt, erhält das abgeleitete Objekt zunächst alle Eigenschaften seines 
Vorgängers. Eigenschaften sind hier natürlich Daten und Methoden des Ob- 
jekts. 


5.2 Ein Beispiel für Vererbung 


Als Beispiel wollen wir eine Ableitung des wndt-Objekts aus dem letzten Ka- 
pitel bilden. 


type Wnd2T = object( WndT ) 
end; {-- Wnd2T } 


Das neue Objekt referenziert seinen Vorgänger durch den in Klammern ge- 
stellten Objektnamen nach dem Schlüsselwort object. In diesem Beispiel 
werden weder neue Datenelemente noch neue Methoden definiert. Da aber 
ein abgeleitetes Objekt alle Daten und Methoden seines Vorgängers erbt, be- 
sitzt Wnd2t bereits das Datenelement Buffer sowie die beiden Methoden open 
und CLose. Es ist also völlig korrekt zu schreiben 


var W : Wnd2T; 
begin 

W.Open( 10, 10, 20, 15 ); 

(... Ausgabe in das Fenster } 
W.Close; 


end. 
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Wichtig ist hier, daß durch die Ableitung keine Kopie des Vaterobjekts er- 
zeugt wird. Zu diesem Zeitpunkt kann noch nichts kopiert werden, da es 
noch keine Instanz gibt. Die Ableitung, aus technischer Sicht die Referenz 
auf das Vaterobjekt, ist nur eine Information für den Compiler, die Daten 
und Methoden des Vorgängers in den Sichtbarkeitsbereich mit aufzunehmen. 


5.3 Neue Eigenschaften 


Das neue Objekt kann weitere Daten und Methoden definieren, die dann zu- 
sätzlich zu den geerbten Eigenschaften vorhanden sind. 


Wir wollen als Beispiel eine neue Methode definieren, die die Änderung der 
Fenstergröße erlaubt. 


type Wnd2T = object( WndT ) 
procedure ReSize( XMin, YMin, XMax, YMax : integer ); 


end; {-- Wnd2T } 


procedure Wnd2T.Resize( XMin, YMin, XMax, YMax : integer ); 
begin 
Window( XMin, YMin, XMax, YMax); 
end; {-- ReSize ) 
Im Hauptprogramm könnte man dann z.B. schreiben 
var W : Wnd2T; 
begin 
W.Open( 10, 10, 20, 15 ); 
while not Keypressed2 do 
Write( char( Random( 26 ) + 65 ) ); 
W.ReSize( 10, 10, 25, 18 ); 


while not Keypressed2 do 
Write( char( Random( 26 ) + 65 ) ); 


W.Close; 
end. 
Es macht keinen Unterschied, ob eine Methode in einem Objekt definiert 


oder geerbt wurde. Geerbte Methoden werden genauso aufgerufen wie neu 
definierte. 
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Warum codieren wir wnd2T.Resize als Methode? Mit dem gleichen Effekt 
könnte man doch gleich window aufrufen. Das ist technisch möglich und wird 
auch von vielen Programmierern so codiert. Es ist im Sinne objektorientier- 
ter Programmierung aber falsch. 


Wir haben anfangs ein Objekt als Baustein zur Lösung eines bestimmten 
Problems definiert. Alle Daten und Verarbeitungsschritte, die zur Lösung 
des Problems erforderlich sind, müssen in das Objekt aufgenommen werden. 


Weiterhin sollen Schnittstellen und Implementierung getrennt sein. Der Nut- 
zer des Objekts soll nichts darüber wissen (müssen), wie das Problem gelöst 
wird. Nur wenn der Nutzer ausschließlich über die Schnittstellen mit dem 
Objekt kommuniziert, kann erreicht werden, daß eine bestehende Implemen- 
tierung durch eine bessere ersetzt werden kann, ohne daß Nutzerprogramme 
ebenfalls geändert werden müssen. 


Da in unserem Fenstersystem die Aufgabe "die Größe eines Fensters verän- 
dern" eindeutig zur Gesamtaufgabe "Fenstersystem" gehört, muß für diese 
Aufgabe auch eine eigene Methode definiert werden. 


5.4 Redefinieren von Eigenschaften 


Wenn in einem Objekt eine Methode neu definiert wird, nimmt diese die 
Stelle der alten ein. Die alte Methode steht dann nicht mehr ohne weiteres 
zur Verfügung. Dieser Redefinitionsmechanismus funktioniert nur bei Me- 
thoden, nicht aber bei Daten. Wird versucht, ein Datenelement zu redefinie- 
ren, meldet der Compiler stattdessen pupl icate Identifier. 


Die Redefinition von Methoden wird häufig verwendet, um abgeleiteten Ob- 
jekten eine verbesserte Funktionalität zu verleihen. Im folgenden Beispiel 
gehen wir davon aus, daß das Objekt wndr wie im letzten Kapitel definiert 
und implementiert wurde. 


Nun sollen die Methoden so erweitert werden, daß doppeltes Öffnen bzw. 
Schließen eines Fensters erkannt wird. Zusätzlich sollen die Fensterkoordi- 
naten im Objekt gespeichert werden. 


Ein erster Entwurf könnte etwa so aussehen: 
type NewWndT = object( WndT ) 


WXMin, WYMin, WXMax, WYMax : integer; 
Status : ( Inactive, Active ); 


procedure Open( XMin, YMin, XMax, YMax : integer ); 
procedure Close; 


end; {-- NewWndT } 
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procedure NewWndT.Open( XMin, YMin, XMax, YMax : integer ); 


var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Active then 
begin 
Writeln( ’Fenster schon offen’ ); 
Exit; 
end; 
WXMin:= XMin; WYMin:= YMin; 
WXMax:= XMax; WYMax:= YMax; 


Status:= Active; 


ScreenBase:= GetScreenBase; 
Move( ptr( ScreenBase, 0 )”“, Buffer, 25*80*2 ); 
Window( XMin, YMin, XMax, YMax ); 


end; {-- Open } 
procedure NewWndT.Close; 
var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Inactive then 

begin 

Writeln( ’Fenster schon geschlossen’ ); 

Exit; 

end; 
WXMin:= 1; WXMax:= 8 

= =2 


WYMin:= 1; WYMax:= 
Status:= Inactive; 


0; 
5; 


ScreenBase:= GetScreenBase; 
Window 1, 1, 80, 25 ); 
Move( Buffer, ptr( ScreenBase, 0 )*, 25%*80%2 ); 


end; {-- Close } 
Um mit den neuen Methoden arbeiten zu können, brauchen die Hauptpro- 


gramme nicht geändert werden. Allerdings müssen die Instanzen nun vom 
Objekt newundt gebildet werden. 
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var W : NewWndT; 


begin 
ClrScr; 
W.Open( 10, 10, 25, 20 ); 
while not Keypressed do 
begin 
Delay( 50 ); 
WriteC char( Random( 26 ) + 65 ) ); 
end; 


W.Close; 


end. 


Durch die Namensgleichheit von geerbten und neudefinierten Methoden kön- 
nen im Hauptprogramm wndT.open und wndT.Close nicht mehr ohne weiteres 
angesprochen werden. Sie sind durch die Methoden newwWndT.open und 
NewWndT.Close Tedefiniert worden. 


Beachten Sie in der Implementierung der neuen Methoden, daß das Daten- 
element Buffer weiterhin zur Verfügung steht. Es macht für die Verwendung 
keinen Unterschied, ob Daten geerbt oder neu definiert werden. 


Obwohl die Implementierung der neuen Methoden ihren Zweck erfüllt, ent- 
spricht sie nicht objektorientiertem Denken. Betrachten wir noch einmal die 
Aufgabenstellung: Die Methoden sollen erweitert werden, um zusätzliche 
Funktionalität zu erhalten. Objektorientiertes Denken verlangt, daß einmal 
entwickelte Strukturen weitestgehend weiterverwendet werden. 


Beschränkt man sich bei der Redefinition von open und Close auf das tatsäch- 
lich Neue und verwendet für die gleichbleibende Funktionalität die geerbten 
Methoden, erhält man folgende, aus Sicht der objektorientierten Program- 
mierung bessere Implementierung von open und Close: 


procedure NewwWndT.Open( XMin, YMin, XMax, YMax : integer ); 


var ScreenBase » word; {-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Active then 

begin 

Writeln( ’Fenster schon offen’ ); 

Exit; 


end; 
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WXMin:= XMin; WYMin: 
WXMax:= XMax; WYMax: 
Status:= Active; 


YMin; 
YMax; 


WndT.Open( XMin, YMin, XMax, YMax ); 
end; {-- Open } 


procedure NewWndT.Close; 


var ScreenBase : word; (-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Inactive then 
begin 
Writeln( 'Fenster schon geschlossen’ ); 
Exit; 
end; 
WXMin:= 1; WXMax:= 80; 
WYMin:= 1; WYMax:= 25; 


Status:= Inactive; 
WndT.CLose; 


end; {-- Close } 


In dieser Implementierung wird Buffer von den neuen Methoden nicht mehr 
benötigt. Die Funktionalität des Sicherns und Wiederherstellens des Bild- 
schirmspeichers bleibt lokal zum Objekt wnar. 


Der wesentliche Vorteil liegt darin, daß eine evtl. später wünschenswerte 
Änderung in der Technik des Speichervorganges auf wndr beschränkt bleibt. 
Wenn der Entwickler von wndr weiß, daß die NachfolgerNachfolgeobjekte die 
wndt-Methoden aufrufen und nicht deren Code duplizieren, kann er die 
Implementierung seines Objekts später problemlos abändern - so lange die 
Definition von wndr unverändert bleibt. Alle Nachfolgeobjekte partizipieren 
dann von dieser Änderung automatisch. 


5.5 Das Initialisierungsproblem 


Die Führung der Variable status in diesem Beispiel bringt eine grundsätzli- 
che Schwierigkeit mit sich, die allerdings nicht auf objektorientierte Pro- 
gramme beschränkt ist. Nach der Instanzierung des Objekts hat status einen 
undefinierten Wert. Erst durch den Aufruf einer Methode wird ein Wert zu- 
gewiesen. Dies kann z.B. zur Folge haben, daß Status nach der Instanzierung 
zufällig den Wert Active hat. Obwohl das Fenster nicht geöffnet ist, kann open 
nicht erfolgreich aufgerufen werden - wohl aber ctose!. 
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In der objektorientierten Programmierung hat man sich deshalb angewöhnt, 
für jedes Objekt, für das diese Initialisierungsproblematik auftritt (also für 
nahezu jedes nicht-triviale Objekt), eine Initialisierungsroutine zu definieren 
und diese nach der Erzeugung der Instanz sofort aufzurufen. Traditionell 
heißen diese Methoden ınit oder Make. 


Analog dazu wird häufig eine gesonderte Beendigungsroutine benötigt, die 
bestimmte Abschlußarbeiten ausführen muß. Diese Methode wird oft kit 
genannt. Insbesondere wenn dynamische Speicherverwaltung verwendet 
wird, sind diese Routinen meist erforderlich. 


In unserem Fall reicht es aus, wenn die Initialisierungsprozedur die Statusva- 
riable auf inactive setzt. Die Implementierung ist trivial: 


procedure NewWndT.Init; 
begin 

Status:= Inactive; 

end; {-- Init } 


In einem Programm wird dann vor einer Verwendung einer Instanz von 
NewWndT die init-Methode aufgerufen. 


5.6 Objekthierarchien 


Von einem Objekt können verschiedene Nachfolger abgeleitet werden, von 
diesen wiederum andere Nachfolger etc. Auf diese Weise können ganze Ob- 
jekthierarchien gebildet werden, jede Stufe ist dabei eine Verfeinerung der 
Vorhergehenden. Eins der wesentlichen Ziele objektorientierter Entwicklung 
ist die geeignete Definition solcher Hierarchien für eine Programmier-Ge- 
samtaufgabe. 


5.7 Beispiel einer Objekthierarchie 


Wir wollen das Fenstersystem und die bisher erarbeiteten Änderungen dazu 
in einer dreistufigen Hierarchie abbilden. Das Ursprungsobjekt soll das im 
vorigen Kapitel entwickelte wnat-Objekt sein. Davon wird das Objekt wnd2Tt 
abgeleitet, das zusätzlich eine Methode zur Änderung der Fenstergröße zur 
Verfügung stellt. Davon wiederum leitet sich das Objekt newwndt ab, das unter 
anderem eine gewisse Sicherheit vor falschem Aufruf der Methoden sowie 
eine Initialisierungsprozedur bietet. 
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type WndT = object 
Buffer : arrayl 1..25*80*2 ] of char; 


procedure Open( XMin, YMin, XMax, YMax : integer ); 
procedure Close; 


end; {-- WndT } 


type Wnd2T = object( WndT ) 
procedure ReSize( XMin, YMin, XMax, YMax : integer ); 


end; {-- Wnd2T } 


type NewWndT = object( Wnd2T ) 


WXMin, WYMin, WXMax, WYMax : integer; 
Status : ( Inactive, Active ); 


procedure Init; 
procedure Open ( XMin, YMin, XMax, YMax : integer ); 
procedure ReSize( XMin, YMin, XMax, YMax : integer ); 


procedure Close; 


end; (-- NewWndT } 


Das Bild 5-1 zeigt, in welcher Beziehung die drei Objekte zueinander stehen. 
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Objekte Eigenschaften 


Buffer 
WndT.Open 
WndT.Close 


Buffer 
WndT.Open 
WndT.Close 
Wnd2T.Resize 


Buffer 

WXMin, WYMin, WXMax, WYMax, Status 
NewWndT NewWndT.Open 

NewWndT.Resize 

NewWndT.Close 


Bild 5-1 Objekthierarchie 


Newwndr ist in dieser Hierarchie direkter Nachfolger von wnd2t und Nachfolger 
von wndt. Beachten Sie in der folgenden Implementierung der Objekte, daß 
NewWndT.Open und NewWndT.Close die entsprechenden Methoden von wnd2T aufru- 
fen, obwohl wnd2tT keine Methoden open oder Ctose definiert. Der Aufruf ist 
nicht nur korrekt (da wna2t die Methoden geerbt hat), sondern auch guter 
Programmierstil. 


{---------- Implementierung Methoden fuer WndT } 

procedure WndT.Open( XMin, YMin, XMax, YMax : integer ); 

var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 

ScreenBase:= GetScreenBase; 

Move( ptr( ScreenBase, 0 )”, Buffer, 25*80*2 ); 

Window( XMin-1, YMin-1, XMax+1, YMax+1 ); 


end; {-- Open } 
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procedure WndT.Close; 

var ScreenBase » word; {-- Segmentaddr. Bildschirmspeicher } 
begin 

ScreenBase:= GetScreenBase; 

Window 1, 1, 80, 25 ); 

Move( Buffer, ptr( ScreenBase, 0 )*, 25*80*2 ); 


end; {-- Close } 


[nn Implementierung Methoden fuer Wnd2T } 
procedure Wnd2T.Resize( XMin, YMin, XMax, YMax : integer ); 
begin 

Window( XMin, YMin, XMax, YMax); 

end; {-- ReSize ) 

[--- 00. Implementierung Methoden fuer NewWndT } 
procedure NewWndT.Init; 

begin 


Status:= Inactive; 
end; (-- Init } 


procedure NewWndT.Open( XMin, YMin, XMax, YMax : integer ); 


var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Active then 
begin 
Writeln( ’Fenster schon offen’ ); 
Exit; 
end; 
WXMin:= XMin; WYMin:= YMin; 
WXMax:= XMax; WYMax:= YMax; 


Status:= Active; 
Wnd2T.Open( XMin, YMin, XMax, YMax ); 


end; {-- Open )} 
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procedure NewWndT.ReSize( XMin, YMin, XMax, YMax : integer ); 


begin 
if Status = Inactive then 
begin 
Writeln( ’Fenster nicht offen’ ); 
Exit; 
end; 
WXMin:= XMin; WYMin:= YMin; 
WXMax:= XMax; WYMax:= YMax; 


Wnd2T.ReSize( XMin, YMin, XMax, YMax ); 
end; {-- ReSize )} 


procedure NewWndT.Close; 


var ScreenBase : word; {-- Segmentaddr. Bildschirmspeicher } 
begin 
if Status = Inactive then 
begin 
Writeln( ’Fenster schon geschlossen’ ); 
Exit; 
end; 
WXMin:= 1; WXMax:= 80; 
WYMin:= 1; WYMax:= 25; 


Status:= Inactive; 
Wnd2T.Close; 


end; {-- Close } 


In einer professionellen Implementierung des Fenstersystems würde man 
wahrscheinlich die Gesamtfunktionalität von Newwndt in nur einem Objekt 
konzentrieren, da wohl niemand wndt oder wnd2r verwenden würde, wenn 
Newwndt ebenfalls zur Verfügung steht. Die drei Objekte sollen ausschließlich 
der Veranschaulichung des Vererbungsmechanismus dienen. 


5.8 Objekte und Units 


Objekte mit ihren Implementierungen können genauso wie normale Daten 
und Prozeduren in Units organisiert werden. Im Interface-Teil deklarierte 
Daten und Objekte können von anderen Units bzw. Programmen verwendet 
werden; die im Implementierungsteil angeordneten Daten und Objekte sind 
nach außen nicht sichtbar. 
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Die einfachste Form der Organisation ist die Plazierung der Objektdefinition 
im Interfaceteil und der Objektimplementierung im Implementierungsteil der 
Unit. Das Objekt kann so von anderen Units und Programmen verwendet 
werden, die Implementierung des Objekts bleibt aber verborgen. 


Diese Organisationsform unterstützt somit das Ziel der objektorientierten 
Programmierung, die Benutzerschnittstelle von der Implementierung zu tren- 
nen. Beachten Sie bitte, daß dieses Ziel nicht durch objektorientierte 
Sprachmittel, sondern durch das bekannte Unit-Konzept erreicht wird. 


Ist ein Objekt im Interface-Teil einer Unit definiert, kann es natürlich auch 
zur Ableitung weiterer Objekte verwendet werden. Es steht außerdem im Im- 
plementierungsteil der Unit zur Verfügung, um z.B. lokale, das heißt auf die 
Unit beschränkte Ableitungen bilden zu können. 


Zur Demonstration verwenden wir wieder unsere Objekthierarchie. Die bei- 
den Objekte wndt und wndet werden in der Unit window untergebracht, das 
Objekt newwndt in der Unit window. Die Hilfsprozeduren GetscreenBase und 
Keypressed2 sind in einer dritten Unit mit dem Namen cenerat plaziert. 


Das Unit-Konzept von Turbo-Pascal ist ein ideales Mittel, um dem Ziel der 
einfachen Wiederverwendbarkeit einmal erstellter Objekte näherzukommen. 
Dazu gehört neben einer guten Dokumentation auch eine geeignete Organi- 
sation des Quelltextes. 


Eine in der Praxis bewährte Möglichkeit dazu besteht in der Aufteilung des 
Textes in einzelne Include-Dateien. Dabei wird nur der Interface-Teil der 
Unit in der eigentlichen Unit-Datei angeordnet, der Implementierungsteil 
wird auf die einzelnen Include-Dateien verteilt. Die Namen der Include-Da- 
teien sind nicht von den Prozedurnamen abgeleitet, da in einer Datei mehrere 
Prozeduren untergebracht sein können. Es hat sich bewährt, die Include-Da- 
teien einfach durchzunumerieren. Dadurch wird die Übersichtlichkeit in ei- 
nem größeren Programmsystem wesentlich erhöht. 


Im folgenden sind die eigentlichen Unit-Dateien aufgelistet. 
Datei General 
unit General; 


interface 
uses Crt, Dos; 


{-- Bildschirmorientierte Routinen --------------------- = - G110 ----) 


const ScreenBytesC 
type ScreenT 


25*80*2; 
array[ 1..ScreenBytesC ] of char; 


function GetScreenBase : word; 
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{-- Tastaturorientierte Routinen ---------------------- G120 ----) 
function Keypressed2 : boolean; 
implementation 


{$I G110 3 {-- Bildschirmorientierte Routinen } 
{$I G120 ) {-- Tastaturorientierte Routinen ) 


end. 


Datei Windowl 
unit Window1; 


interface 
uses Crt, General; 


{-- Basisfenster ----------------------- HH 00000 w110 ----) 
type WndT = object 
Buffer : ScreenT; (-- Gesamter Bildschirm } 
procedure Open( XMin, YMin, {-- links oben } 


XMax, YMax : integer ); {-- rechts unten } 
procedure Close; 


end; {-- WndT } 


type Wnd2T = object( WndT ) 


procedure ReSize( XMin, YMin, {-- Links oben } 
XMax, YMax : integer ); {-- rechts unten } 


end; {-- Wnd2T } 


implementation 


{$1 W1103 £-- WndT, Wnd2T } 
{$1 W120} (-- NewwWndT } 


end. 
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Datei Window2 


unit Window2; 


interface 
uses Window; 


type NewWndT = object( Wnd2T ) 


WXMin, WYMin, WXMax, WYMax : integer; 
Status : ( Inactive, Active ); 


procedure Init; 


procedure Open ( XMin, YMin, XMax, YMax : integer ); 
procedure ReSize( XMin, YMin, XMax, YMax : integer ); 
procedure Close; 


end; {-- NewWndT } 
implementation 
{$I W2103 (-- NewWndT } 
end. 


Die Include-Dateien enthalten die Implementierung der im Interface-Teil de- 
klarierten Prozeduren und Objekte. Bei der Aufteilung sollten inhaltlich zu- 
sammengehörige oder ähnliche Routinen auch in einer Datei angeordnet wer- 
den. Aus diesem Grunde sind z.B. die Methoden wndT.open und WndT.Close in 
einer Datei, nicht aber die Prozeduren GetScreenBase und KeyPressed2. 


Auf den Abdruck der Implementierungsteile wird aus Platzgründen verzich- 
tet. Gegenüber den früheren Listings hat sich auch nicht viel geändert, ledig- 
lich die Konstante für die Anzahl Bytes des Bildschirmspeichers sowie der 
Typ screent sind hinzugekommen. 


5.9 Zuweisung von Objekten 


Abgeleitete Objekte haben die besondere Eigenschaft, daß sie zu ihren Vor- 
gängern zuweisungskompatibel sind. Einer Variablen eines Objekttyps kön- 
nen also auch Instanzen der Nachfolger dieses Objekts zugewiesen werden. 


Betrachten wir wieder unsere Objekthierarchie mit den Definitionen 


var W1 : WndT; 
W2  : Wno2T; 
W  : NewWndT; 
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Da wna2t ein Nachfolger von ungrt ist, kann jederzeit die Zuweisung 


vorgenommen werden. Bei dieser Zuweisung wird der Datenbereich von wı 
durch den Datenbereich von u2 ersetzt, d.h. aus technischer Sicht wird die 
Anweisung 


W1.Buffer:= W2.Buffer; 


ausgeführt. Die Instanz wı erhält außer dem Datenbereich keine weiteren Ei- 
genschaften von w2. Es ist z.B. nicht möglich, nach der Zuweisung etwa 


W1.Resize(...); 


zu schreiben. Dieses Konstrukt würde bereits bei der Übersetzung abgelehnt, 
da wı eine Instanz von wndt ist und wnat keine Resize-Methode definiert. Diese 
wird auch zur Laufzeit durch eine entsprechende Zuweisung nicht verfügbar. 


Die umgekehrte Zuweisung, also hier 


ist nicht möglich. Warum das so ist, wird im nächsten Beispiel deutlich. Be- 
trachten wir die Zuweisung 


Hier sind die Datenbereiche der beiden Instanzen unterschiedlich groß, trotz- 
dem ist die Anweisung syntaktisch korrekt. Auch hier wird der Datenbereich 
von w2 durch den Datenbereich von w3 ersetzt, wie oben wird also die analoge 
Anweisung 


W2.Buffer:= W3.Buffer; 


ausgeführt. Die in w3 zusätzlich vorhandenen Daten werden aber nicht kopiert 
und gehen verloren. Bei der umgekehrten Zuweisung könnte zwar Buffer be- 
setzt werden, aber die Variablen wxmin bis wYMax sSOWie Status blieben unbe- 
setzt. Der Datenbereich der Instanz w3 würde damit in zwei Teile geteilt, von 
denen einer die Daten von w2, der andere aber immer noch den Zustand vor 
der Zuweisung repräsentiert. 


Dies ist offensichtlich nicht sinnvoll und kann zu gefährlichen Situationen 
führen. Aus diesem Grunde weist der Compiler die Zuweisung einer Instanz 
an eine Variable eines Nachfolgertyps zurück. Beachten Sie bitte, daß diese 
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Zuweisungsregel auch für die Parameterübergabe bei Prozeduren sowie für 
die dynamische Verwaltung von Objekten gilt. 


Hat man z.B. die Deklarationen 
var WIiP : ”WndT; 


W2EP : "Wnd2T; 
W3P : ”NewwWndT; 


so sind die Zuweisungen 


wi 
wir 


W2; 
we” 


zulässig, die umgekehrten Zuweisungen jedoch nicht. 


Diese erweiterte Zuweisungskompatibilität ist eines der wesentlichen neuen 
Konzepte der objektorientierten Programmierung. Es war bisher nicht mög- 
lich, Daten verschiedenen Typs an ein- und dieselbe Variable zuzuweisen. 
Die Zuweisung numerischer Größen (z.B. integer auf byte) ist insofern eine 
Ausnahme, als dort eine implizite Typumwandlung durchgeführt wird. Aber 
diese Typumwandlung hat ihre Tücken, z.B. wenn die integer-Variable einen 
Wert größer als 255 hat oder negativ ist. 


Die daraus entstehenden Probleme sind vergleichbar mit der eingangs darge- 
stellten Problematik am Beispiel der Dateninterpretation von Income und Temp. 
Sie haben gemeinsam, daß sie erst zur Laufzeit des Programms auftreten und 
auch nur bei bestimmten Datenkonstellationen zu Fehlern führen. 


In der objektorientierten Programmierung werden diese Probleme auf den 
Compiler verlagert, d.h. sie können bereits bei der Übersetzung erkannt 
werden. Die Zuweisung von Objekten ist deshalb nur in der Richtung mög- 
lich, in der sich nach der Zuweisung wieder ein sicherer Zustand der Daten 
ergibt. 


Das Konzept ist so neu, daß es auf den ersten Blick schwerfällt, ein geeigne- 
tes Beispiel zu finden. Nach kurzer Gewöhnungszeit kann man aber damit 
Probleme so elegant lösen, wie es im klassischen Pascal nicht vorstellbar 
wäre. Betrachten wir z.B. ein Urfensterobjekt ähnlich unserem wnat. Davon 
seien mehrere Nachfolger abgeleitet, z.B. Fenster mit Rahmen, speziellen 
Funktionen wie integriertem Editor oder anderen Eigenschaften. 


Sind mehrere solcher Fenster offen, verwaltet man diese im allgemeinen mit 
einem Kellerspeicher. Deklariert man die Datenelemente des Kellerspeichers 
als Zeiger auf wndtr, kann man diesem Zeiger auch Instanzen aller anderen 
Fensterobjekte zuweisen und damit im Kellerspeicher ablegen. 


Diese Eigenschaft von Objekthierarchien kann ganz allgemein dazu verwen- 
det werden, verschiedene Datentypen z.B. in einer linearen Liste zu verwal- 
ten. Der Vorteil liegt darin, daß man bei Entwurf und Implementierung der 
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Prozeduren zum Aufbau und Pflege der Liste noch nicht wissen muß, welche 
Daten später damit verwaltet werden sollen. Die Routinen zur Verwaltung 
der Liste müssen nur einmal erstellt (und getestet) werden. Darüber hinaus 
ist der Maschinencode nur einmal im Programm vorhanden, auch wenn meh- 
rere Listen aufgebaut werden müssen. 


5.10 Explizite Typumwandlung 


Explizite Typumwandlungen kommen meistens im Zusammenhang mit der 
dynamischen Verwaltung von Objekten vor. Typumwandlungen sind aber 
auch mit statischen Instanzen möglich. 


Hat man z.B. das Programmstück 


uses Window1, Windon2; 
var W1 : WndT; 


begin 
W1.Open( 3, 3, 10, 10 ); 


ausgeführt, ist der Aufruf von Resize nicht möglich, da Resize in wndt nicht de- 
finiert ist. Der Programmierer kann nun wı explizit zum Typ wndat 
"befördern" und dann eine in und2t definierte Methode aufrufen. 


Die Anweisung 


Wnd2TC W1 ).Resize( 10, 10, 15, 15 ); 


ist erlaubt und führt in diesem Fall auch zu einem sinnvollen Ergebnis, denn 
Resize verwendet nur die bereits in wndr definierten Daten. 


Das muß nicht unbedingt so sein. Allgemein läßt Turbo-Pascal eine Typum- 
wandlung zu, wenn die Datenbereiche beider Objekte die gleiche Größe ha- 
ben. Die obige Typumwandlung ist aus diesem Grunde erlaubt, nicht aber 
die Umwandlung 


NewWndT( W1 ).Resize( 10, 10, 15, 15 ); 


Diese Anweisung würde selbst dann zu einer Invalid type cast Meldung füh- 
ren, wenn Resize nur geerbt wäre und deshalb die eigentlich erlaubte Routine 
Wnd2T.Resize verwendet würde. 


Der Compiler prüft vor einer Typumwandlung nur, ob die Datenbereiche die 
gleiche Größe haben. Betrachtet man die Datenelemente des Objekts wieder 
als record, erkennt man die Analogie zum klassischen Pascal: auch dort sind 
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explizite Typumwandlungen nur möglich, wenn Quell- und Zieltyp die glei- 
che Größe haben. 


Für die Typumwandlung von Objekten ergibt sich daraus eine weitere Kon- 
sequenz: Da abgeleitete Objekte alle Datenelemente ihrer Vorgänger erben, 
kann ihre Größe nur zunehmen, höchstens aber gleichbleiben. Eine Beförde- 
rung, also die explizite Typumwandlung in Richtung nachfolgender Objekte 
ist nur dann möglich, wenn der Nachfolger keine zusätzlichen Daten defi- 
niert. 


Da die meisten abgeleiteten Objekte mehr Eigenschaften und deshalb meist 
auch mehr Daten definieren, ist die Beförderung durch explizite Typum- 
wandlung nicht möglich. Diese Tatsache stellt eine wesentliche Einschrän- 
kung dar. Möchte man z.B. den bereits erwähnten Kellerspeicher zum Spei- 
chern verschiedener Datentypen entwickeln, wird man die Prozeduren zum 
Speichern und Zurückholen vielleicht Push und Pop nennen. Das Problem 
tritt dann auf, wenn man den Typ der Parameter für diese Prozeduren festle- 
gen muß. 


Nehmen wir weiter an, daß die Datenelemente, die gespeichert werden sol- 
len, als Objekte formuliert sind und einer Klasse (das heißt einer Objekthie- 
rarchie) angehören. Der Urvater, das heißt der Vorgänger aller Objekte, soll 
ure&lmt heißen. Alle Objekte dieser Klasse sind damit direkte oder indirekte 
Nachfolger von ureint. 

Es ist sofort klar, daß eine Variable, die 


zuweisungskompatibel zu allen Objekten dieser Klasse sein soll, vom Typ 
UrElmt sein muß. Es liegt also nahe, die Prozeduren des Kellerspeichers wie 
folgt zu deklarieren: 


procedure Push( E : UrElmT ); 
procedure Pop( var E : UrElmT ); 


Beachten Sie bitte, daß Pop nicht als function formuliert werden kann, da 
UrElmt nicht notwendigerweise ein einfacher Datentyp sein muß. Nun kann 
man Push mit einer Instanz eines beliebigen Nachfolgers von ureEimt aufrufen. 
Das ist syntaktisch korrekt, liefert aber nicht das gewünschte Ergebnis. 


Hat man ein solches Objekt etwa als 
type ElmT = object( UrElmT ) 


X,Y,Z : real; 
end; {-- ElmT } 


und eine Instanz mit 


var Elm : ElnT; 


definiert, ist die Anweisung 
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Push( Elm ); 

syntaktisch richtig. Bei der Ausführung des Prozeduraufrufes wird die in- 
terne Zuweisung 

E:= Elm; 


ausgeführt. Das bedeutet nach den Zuweisungsregeln, daß x, v und z nicht 
kopiert werden können und demzufolge auch nicht gespeichert werden. 


Umgekehrt liefert pop ein Objekt vom Typ ureimt zurück. Es ist nicht mög- 
lich, ein solches Objekt wieder zum ursprünglichen Typ Eimt zu befördern, 
da die Werte für x ‚v und z nicht vorhanden sind. 


Die Konstruktion 


Pop( Elm ); 


ist unzulässig, da bei Aufruf der Prozedur die implizite Zuweisung 

Elm:= E; 

durchgeführt würde. Diese ist nach den Zuweisungsregeln nicht erlaubt. Das 
läßt sich auch durch eine explizite Typumwandlung nicht umgehen: 


var UrElm : UrElnT; 


Pop( UrElm ); 
Elm:= ElmT( UrElm ); 


Hier übersetzt der Compiler zwar den Prozeduraufruf noch, bricht dann aber 
bei der nächsten Anweisung mit Invalid type cast ab. 


5.11 Explizite Typumwandlung mit Zeigern 


Die Lösung des Beförderungsproblems liegt in der Verwendung von Zei- 
gern. Wir definieren die beiden Objekte zusammen mit den zugehörigen Zei- 
gertypen wie folgt: 


type UrElmT object 


end; 


UrElmPT = “UrElnT; 
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type ElmT = object( UrElmT ) 
X,Y,Z : real; 
end; {-- ElmT ) 


ElmPT ‘ENT; 
Hier fällt auf, daß ureimr weder Daten noch Methoden definiert. Wozu kann 
man eine Instanz dieses Objekts verwenden? ureimt wird in diesem Beispiel 
nicht zur Erzeugung von Instanzen verwendet, sondern dient ausschließlich 
als Urvater zur Ableitung der eigentlichen Objekte. Solche Objekte nennt 
man auch polymorphische Objekte. 


Elmr enthält nur Daten und keine Methoden. Das Objekt hätte deshalb auch 
als record deklariert werden können. In diesem Beispiel wird ausschließlich 
von der Zuweisungskompatibilität in der Objekthierarchie Gebrauch ge- 
macht. Auf die Eigenschaft eines Objekts zur Klammerung von Daten und 
Algorithmen kommt es hier nicht an. 


Die beiden Prozeduren des Kellerspeichers erwarten bzw. liefern nun Zeiger 
vom Typ ureimet. 


procedure Push( EP : UrElmPT ); 
function Pop : UrElmPT; 


Da ein Zeiger ein einfacher Datentyp ist, kann pop nun als function deklariert 
werden. In folgendem Programmsegment wird eine Instanz von Eimt erzeugt 
und im Kellerspeicher abgelegt. 


var EP1 : ElmPT; 
begin 


New( EP1 ); 
Push( EP1 ); 


Die implizite Zuweisung ep:= Ep1 bei Aufruf von Pushc Ep1 ) ist zulässig und 
führt nicht zu Datenverlusten, da ja nicht der Datenbereich des Objekts sel- 
ber, sondern nur ein Zeiger auf diesen Bereich kopiert wird. Beachten Sie 
bitte, daß bei der Übersetzung trotzdem an Hand der Typen von er und ep1 
geprüft wird, ob die Zuweisung syntaktisch korrekt ist. 


Innerhalb von push zeigt er nun auf eine vollständige Instanz von Elnt, 
obwohl ep selber nur vom Typ ureimprt ist. Dies bedeutet, daß innerhalb von 
Push nicht auf die Daten x ‚y und z von Eim zugegriffen werden kann. Ein 
Ausdruck wie ep“.x ist unzulässig, da x, y und z in ureimr nicht definiert sind. 


Dies ist kein Nebeneffekt, sondern gewollt: push soll ja die Daten von ep 
nicht verändern, sondern die Instanz als Ganzes ablegen. Dazu wird aber 
keine Kenntnis über den internen Audbau des Objekts benötigt. Bei der Pro- 
grammentwicklung gibt dies zusätzliche Sicherheit vor irrtümlicher Manipu- 
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lation von Daten. Dieser Sicherheitsgewinn ist bei großen Programmiervor- 
haben mindestens genauso wichtig wie die Möglichkeit, Daten beliebiger 
Typen bearbeiten zu können. 


Hat man im Kellerspeicher nur Instanzen von Eimt abgelegt, kann man zum 
Wiedergewinnen z.B. folgendes Programmsegment verwenden: 


var EP1 : ElmPT; 
var UrElm : UrElmPT; 
begin 

UrElmP:= pop; 


EPl:= ElmPTC UrElmP ); 
Writeln( EP1”.X ); 


Nach dem Aufruf von Pop zeigt urElmp auf eine Instanz von Eimt. Um wieder 
auf die Datenfelder x, y und z zugreifen zu können, muß diese Instanz 
zunächst wieder zum Typ Eimt befördert werden. Diese Beförderung muß 
grundsätzlich durch eine explizite Typumwandlung vom Programmierer vor- 
genommen werden. Die Wandlung ist zulässig, da Quell- und Zieldatentyp 
beides Zeiger und deshalb gleich groß sind. Hier kommt es also nicht auf die 
eigentliche Objektgröße an. 


Diese Typumwandlung über Zeiger ist die einzige Möglichkeit, Instanzen in 
der Objekthierarchie wieder zu befördern. Entsprechend oft wird in der ob- 
jektorientierten Programmierung davon Gebrauch gemacht. Es darf jedoch 
nicht übersehen werden, daß prinzipiell jeder Zeigertyp in jeden anderen 
Zeigertyp umgewandelt werden kann. Man hätte im obigen Beispiel syntak- 
tisch richtig genauso gut schreiben können 


WndPTC UrElmP ); oder 
NewWndPT(C UrElmP ); 


wi: 
W2: 


die entsprechenden Deklarationen von wndPT und NewwndpT vorausgesetzt. Die 
Folge: Da der Datenbereich von newwndt größer als der von Eint ist, bewirkt 
z.B. die Anweisung w2*.Resize ein Überschreiben von Speicherbereichen, die 
nicht zum Objekt gehören. 


Der Programmierer setzt hier vorsätzlich die von Turbo-Pascal angewende- 
ten Typprüfungen außer Kraft. Leider kann bei Problemen der dargestellten 
Art nicht auf die explizite Typumwandlung verzichtet werden. In bestimmten 
Fällen kann dieser Mangel im Konzept der objektorientierten Programmie- 
rung etwas gemildert werden, wie wir im Kapitel über virtuelle Methoden 
sehen werden. 


Ein weiteres Problem tritt auf, wenn Instanzen verschiedener Objekte im 
Kellerspeicher verwaltet werden sollen. Wenn diese Objekte zur gleichen 
Klasse (d.h. zur gleichen Objekthierarchie) gehören, können sie problemlos 
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mit push abgelegt werden. Nach einem Aufruf von pop weiß man dann aber im 
allgemeinen nicht, welches Objekt die erhaltene Instanz repräsentiert. Viele 
Programmierer helfen sich mit einer Statusvariablen im Objekt ureimt, die 
von allen Nachfolgern in eindeutiger Weise gesetzt und später in einer case- 
Anweisung ausgewertet werden kann. 


Der im nächsten Abschnit vorgestellte vollständige Kellerspeicher verwendet 
diesen Ansatz. 


5.12 Fallstudie Kellerspeicher 


Wir wollen in diesem Abschnitt das letzte Beispiel aufgreifen und einen ein- 
fachen Kellerspeicher entwickeln. Bis jetzt war es nicht notwendig, die Rou- 
tinen Push und Pop tatsächlich anzugeben. Für das Verständnis der Problema- 
tik expliziter Typumwandlungen waren sie nicht erforderlich. 


Die Entwicklung soll aus zwei verschiedenen Blickwinkeln betrachtet wer- 
den: Einmal aus der Sicht des Entwicklers, der seine Routinen vielleicht als 
Unit zur Verfügung stellen möchte, und zum anderen aus der Sicht des Nut- 
zers, der diese Routinen zur Speicherung seiner Daten verwenden möchte. 


Die Implementierung des Speichers als array wurde der Einfachheit halber 
gewählt. Es soll hier in erster Linie gezeigt werden, wie ein Algorithmus zur 
Datenbearbeitung formuliert werden kann, ohne auf den eigentlichen Daten- 
typ Bezug nehmen zu müssen. Später können die Routinen immer noch pro- 
fessioneller gestaltet werden, z.B. als lineare Liste. 


Der Entwickler der Unit steht vor dem grundsätzlichen Problem, daß er nicht 
weiß, welche Daten ein späterer Nutzer im Kellerspeicher ablegen will. Er 
muß deshalb ein Urelement deklarieren, von dem später die eigentlichen Da- 
tenelemente abgeleitet werden können. Dieses Urelement muß als Objekt de- 
klariert und von der Unit exportiert werden. Die Routinen des Kellerspei- 
chers arbeiten mit diesem Datentyp. 


Der Entwickler ist sich über die Problematik der Beförderungen in Ob- 
jekthierarchien zwar bewußt, stattet sein Urobjekt aber trotzdem nicht mit ei- 
ner Statusvariablen aus. Möchte der Anwender dieser Unit nur einen Daten- 
typ speichern, wäre diese Variable überflüssig. 


Die aus diesen Vorgaben entwickelte Lösung sieht folgendermaßen aus: 


unit StackU; 
{ 


StackT definiert einen Stack mit 10 Elementen. 
Push legt ein Element ab, liefert true wenn noch Platz 
fuer ein weiteres Element ist. 
Pop liefert eine Element, nil wenn Stack leer ist. 
} 
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interface 
{-- Urtyp eines Stackelements ---------------------- = -- 7700000 > 
type StackElmT = object 
end; 
StackElmPT = *StackElmT; 
{-- Der Stack selber ------------------ 207-0 s110 --------- } 
const MaxEntriesC = 10; 
type StackT = object 
Buffer : array[ 1..MaxEntriesC ] of StackElmPT; 
Index : integer; 


procedure Make; 
procedure Kill; 


function Push( EP : StackElmPT ) : boolean; 
function Pop : StackElmPT; 
end; {-- StackT } 


implementation 


{$1 S110 3 C-- Make, Kill } 
{$1 S120 } (-- Push, Pop } 


end. 


Diese Datei veröffentlicht der Entwickler an alle Nutzer der Unit. Der Im- 
plementationsteil sieht folgendermaßen aus: 


Dateı S110 


{--- Implementierung StackT Make, Kill ----) 


procedure StackT.Make; 
begin 

Index:= 1; 

end; {-- Make } 


procedure StackT.Kill; 
begin 
end; {-- Kill } 
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Datei S120 


{--- Implementierung StackT Push, Pop --) 


function StackT.Push( EP : StackElmPT ) : boolean; 
begin 


if Index = MaxEntriesC then {-- Speicher voll. EP nicht eintragen } 
begin 
Push:= false; 
Exit; 
end; 


Buffer[ Index ] := EP; 
Inc( Index ); 
Push:= true; 


end; {-- Push } 


function StackT.Pop : StackElmPT; 
begin 


if Index = 1 then {-- Speicher leer. nil zurueckliefern } 
begin 
Pop:= nil; 
Exit; 
end; 


Dec( Index ); 
Pop:= Buffer[ Index ]; 


end; {-- Pop } 


Der Nutzer dieser Unit möchte zwei verschiedene Datentypen speichern: ein- 
fache reat-Zahlen und Zeichenketten. Er leitet in seinem Programm zunächst 
das Objekt MyStackEimt ab, das eine Statusvariable zur späteren Unterschei- 
dung dieser beiden Objekte definiert: 


type MyStackElmT = object( StackElmT ); 
Status : ( RealO, StringO ); 
end; 


Von diesem Objekt wiederum werden die eigentlichen Nutzerdaten abgelei- 
tet. 


type RealT = object( MyStackT ) 
R : real; 
end; 
RealPT = "RealT; 
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type StringT object( MyStackT ) 


S : string; 
end; 
StringPT = *StringT; 


Ein Programm zur Nutzung des Kellerspeichers könnte unter Verwendung 
dieser Routinen etwa so aussehen (Datei TestS): 


Program TestStack; 


uses StackU; 


type MyStackElmT = object( StackElmT ) 
Status : ( RealO, StringO ); 
end; 
MyStackElmPT = *MyStackElmT; 
type RealT = object( MyStackElnT ) 
R : real; 
end; 
RealPT = *RealT; 
type StringT = object( MyStackElmT ) 
S : string; 
end; 
StringPT = *StringT; 
var RP : RealPT; 
SP : StringPT; 
P : StackElmPT; 
Stack : StackT; 
DummyBool : boolean; 
begin 
Stack.Make; 
New( RP ); 
with RP” do 
begin 
Status:= RealO; 
R:= 10; 
end; 


DummyBool: Stack.Push( RP ); 
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New( SP ); 
with SP” do 
begin 
Status:= StringO; 
S:= 'ABCDEF’; 
end; 
DummyBool := Stack.Push( SP ); 


{-- Hier werden die Daten wieder gelesen } 


P:= Stack.Pop; 
while P <> nil do 


begin 
case MyStackElmPT( P )*.Status of 
RealO : begin 


RP:= RealPT( P ); 
Writeln( RP’.R ); 
Dispose( RP ); 
end; 


StringO : begin 
SP:= StringPT( P ); 
Writeln( SP”.S ); 
Dispose( SP ); 
end; 

end; {-- case ) 

P:= Stack.Pop; 

end; (-- while > 


Stack.Kill; 
end. 


In diesem Programm muß der Nutzer der Unit stacku über die Implementie- 
rung der Routinen nichts wissen. Selbstdefinierte Datentypen können gespei- 
chert werden, solange der Nutzer sicherstellt, daß die zurückgelieferten Zei- 
ger wieder richtig befördert werden. 


Dies ist nicht nur erforderlich, um auf die Daten selber wieder zugreifen zu 
können, sondern auch, um den mit new angeforderten Speicherplatz wieder 
richtig zurückgeben zu können. Es reicht z.B. nicht aus, nach dem Aufruf 
von Pop Einfach Disposec P ) zu schreiben, da der Basistyp von p nicht die 
richtige Größe hat und deshalb die falsche Anzahl Bytes zurückgegeben 
würde. 


Man sieht an diesem Beispiel, daß es nützlich ist, zu jedem Objekt gleich den 
zugehörigen Zeigertyp mitzudefinieren, da diese Typen in expliziten Typ- 
umwandlungen gebraucht werden. Durch eine geeignete Namengebung die- 
ser Typen wird die Lesbarkeit der Typumwandlung erheblich erhöht. 


Was wurde in diesem Beispiel gegenüber einer konventionellen Implementie- 
rung gewonnen? Betrachten wir dazu kurz eine mögliche Implementierung 
mit konventionellen Sprachmitteln. In konventionellem Pascal löst man das 
Problem der allgemeinen Datentypen normalerweise mit generischen Zei- 
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gern. Push und Pop erhalten bzw. liefern Zeiger vom allgemeinen Typ pointer, 
die auf die Nutzerdatenblöcke zeigen. Dadurch kann auch hier die Unit 
datenunabhängig gehalten werden. Es bleibt weiter die Aufgabe des Haupt- 
programms, die Datenblöcke zu erzeugen und mit Werten zu versorgen. Da- 
bei kann auf die Statusvariable auch hier nicht verzichtet werden, da Pop spä- 
ter nur einen allgemeinen Zeiger zurückliefert, der vom Nutzerprogramm 
wieder richtig interpretiert werden muß. Auch das Problem der richtigen 
Rückgabe der Speicherblöcke bleibt bestehen. Der Quellcode des Hauppro- 
gramms in konventioneller Notation unterscheidet sich deshalb nicht wesent- 
lich von der objektorientierten Version. 


Was wurde also gewonnen? In diesem einfachen Beispiel noch nicht viel. Ein 
Grund liegt darin, daß die objektorientierte Lösung die Objekte Reatt und 
Stringr nur als traditionelle records benutzt, denn es werden keine Methoden 
definiert. Die Behandlung von Datenelementen in Objekten unterscheidet 
sich aber nicht wesentlich von der in traditionellen records. 


In diesem Beispiel wurde nur die erweiterte Zuweisungskompatibilität in 
Objekthierarchien ausgenutzt, und hier zeigt sich doch ein Unterschied zur 
konventionellen Implementierung. Wenn das Argument von Push ein 
generischer Zeiger ist, können beliebige Adressen übergeben werden. In der 
objektorientierten Version können aber nur Zeiger übergeben werden, deren 
Basistyp ein Element der Objekthierarchie ist. In größeren Programmen wird 
dadurch die Menge an syntaktisch möglichen Zuweisungen erheblich kleiner. 
Auf diese Weise wird zusätzlich Sicherheit gewonnen. 


Betrachten wir zum Abschluß des Vergleichs die objektorientierte und die 
konventionelle Implementierung des eigentlichen Kellerspeichers. 


In der konventionellen Implementierung muß der Entwickler der Unit einen 
Datentyp deklarieren, der Buffer und index enthält, etwa wie in der folgenden 
Deklaration: 


type StackT = record 
Index : integer; 
Buffer : array[ 1..MaxEntriesC ] of pointer; 
end; 


Die Routinen des Kellerspeichers erhalten einen zusätzlichen Parameter die- 
ses Typs, also z.B. 


procedure Init( var S : StackT ); 

procedure Kill( var S : StackT ); 

function Push( var S : StackT; P : pointer ) : boolean; 
function Pop( var S : StackT ) : boolean; 


Hier zeigt sich der in früheren Kapiteln bereits dargestellte notationelle Un- 
terschied zwischen den beiden Versionen. In der objektorientierten Version 
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kann der Programmierer auf den zusätzlichen Parameter s verzichten, da der 
Compiler ihn in Form des seıf-Parameters automatisch hinzufügt. Betrachtet 
man die objektorientierte Implementierung des Kellerspeichers als isolierte 
Routinen, ist auch hier kein wesentlicher Unterschied zur konventionellen 
Implementierung zu erkennen. 


Der große Vorteil der objektorientierten Implementierung tritt jedoch dann 
zutage, wenn der Kellerspeicher erweitert werden soll. Nehmen wir dazu an, 
daß in einer speziellen Anwendung die Anzahl der gerade auf dem Stack be- 
findlichen Elemente von Interesse ist. Der Entwickler der Unit hat diesen 
Fall aber nicht vorausgesehen und deshalb keine solche Möglichkeit defi- 
niert. Mit Hilfe des Ableitungsmechanismus ist es nun problemlos möglich, 
den Kellerspeicher entsprechend zu erweitern. 


uses StackU; 

type SpecialStackT = object( StackT ) 
NbrOfEntries : integer; 
procedure Make; 
function Push( EP : StackElmPT ) : boolean; 
function Pop : StackElmPT; 
function GetNbrOfEntries : integer; 
end; {-- SpecialStackT } 


{--- Implementierung der redefinierten Methoden --} 


procedure SpecialStackT.Make; 
begin 


StackT .Make; 
NbrOfEntries:= 0; 


end; {-- Make } 
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function SpecialStackT.Push( EP : StackElmPT ) : boolean; 
var Flag : boolean; 
begin 


Flag:= StackT.Push( EP ); 
Push:= Flag; 
if Flag then 

Inc( NbrOfEntries ); 


end; {-- Push } 
function SpecialStackT.Pop : StackElmPT; 


var P : StackElmPT; 


:= StackT.Pop; 
op:= P; 
if P <> nil then 
Dec( NbrOfEntries ); 
end; {-- Pop } 
{--- Implementierung der neuen Methode --) 


function SpecialStackT.GetNbrOfEntries : integer; 
begin 

GetNbrOfEntries:= NbrOfEntries; 

end; {-- GetNbrOfEntries )} 


Beachten Sie, wie in der Implementierung der Methoden dieses Objekts von 
der Funktionalität des bereits definierten Kellerspeichers Gebrauch gemacht 
wird. Nur die zusätzliche Funktionalität muß implementiert werden. 


Wie oft schon wurde der Kellerspeicher von Programmierern neu erfunden 
und jedesmal speziell für eine Aufgabe neu implementiert, einmal mit 
GetNbrofEntries, ein anderes Mal vielleicht mit einer Möglichkeit zum Zugriff 
auf das "unterste" Element? Bei einer Aufgabe wie dem Kellerspeicher ist 
dieser Aufwand noch tragbar. Aber bereits bei etwas komplizierteren Struk- 
turen wie z.B. einer Hash-Tabelle sieht die Sache anders aus. 


Auch hier wird das ein- oder andere Programm zusätzliche Funktionalität 
benötigen. Wenn dann der Hash-Speicher als Objekt formuliert ist, Kann sich 
der Programmierer seine eigene Version mit den erforderlichen Erweiterun- 
gen selber definieren, indem er ein geeignetes Objekt ableitet. Damit soll 
nicht gesagt sein, daß eine solche Erweiterung mit konventionellen Sprach- 
mitteln nicht möglich ist. Selbstverständlich, aber eben nicht so elegant und 
klar, und damit eben nicht so wartungsfreundlich. 
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Trotzdem ist die vorgestellte Lösung noch nicht befriedigend. Vor allem der 
Zwang zur Konvertierung des zurückgelieferten Zeigers zum eigentlichen 
Nuztzdatentyp ist unschön. Im Kapitel 7 mit dem Thema virtuelle Methoden 
werden wir Möglichkeiten kennenlernen, diesen Nachteil zumindest teilweise 
zu vermeiden. 


5.13 Etwas Technik 


Wie löst der Compiler Referenzen auf die verschiedenen Methoden in einer 
Objekthierarchie auf? 


Im folgenden Hauptprogramm wird die Objekthierarchie aus Abschnitt 5.7 
vorausgesetzt. 


var W1 : WndT; 
W2 © Wnd2T; 
W3 : NewWndT; 


begin 
W1.Open( 10, 10, 25, 20 ); 


wW2.Open( 12, 12, 27, 22 ); 
W2.Resize( 12, 12, 30, 23 ); 
W2.Close; 


W3.Init; 
W3.Open( 12, 12, 17, 15 ); 
W3.Close; 


Wenn der Compiler in diesem Programm auf die Anweisung w2.open(...) 
stößt, wird zuerst geprüft, ob das aktuelle Objekt eine Methode dieses Na- 
mens definiert. Das aktuelle Objekt ist hier under, da w2 eine Instanz dieses 
Objektes ist. Da keine passende Methode gefunden wird, wird der nächste 
Vorgänger in derselben Weise überprüft. Der Compiler läuft so in der Ob- 
jekthierarchie nach oben, bis entweder die Methode gefunden wird oder das 
oberste Objekt erreicht ist, für das kein Vorgänger mehr definiert ist. Im 
letzteren Falle wird die Übersetzung mit der Fehlermeldung rietd Identifier 
expected abgebrochen. 


Die Anweisung w2.open ruft also die Methode wndTt.open auf. Da der Compiler 
immer die zuerst gefundene Methode einsetzt, bleiben weiter oben in der 
Hierarchie definierte Methoden gleichen Namens bei der Suche unberück- 
sichtigt. Sie wurden redefiniert. Dieser Fall tritt z.B. bei der Übersetzung 
der Anweisung w3.openc..) auf. Die aktuelle Methode (hier newwndt) definiert 
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bereits eine passende Methode, so daß die Suche gar nicht erst begonnen 
wird. 


Bei der Suche nach einer Methode wird beim aktuellen Objekt begonnen. Im 
Falle von w1.open oder w2.open kann das aktuelle Objekt über die Instanz be- 
stimmt werden: wı ist eine Instanz von wndt, w2 eine von wndat. Ein Objekt 
kann jedoch auch über seinen vollständigen Namen referenziert werden. In 
der Implementierung von NewwndT.open z.B. wird wnd2T.Open aufgerufen. Damit 
ist der Startpunkt der Suche ebenfalls eindeutig definiert. 


Durch vollständige Referenzierung steht eine redefinierte Methode natürlich 
auch im Hauptprogramm weiter zur Verfügung. Bei korrektem Entwurf der 
Objekthierarchie ist dies allerdings überflüssig, denn sonst hätte die Methode 
nicht redefiniert werden dürfen. 


Eine sinnvolle Ausnahme zeigt das folgende Beispiel. Hier wird mit Hilfe 
des Adressoperators festgestellt, ob die Methode open redefiniert wurde. 


if aWndT.Open = aWnd2T.Open then 

Writeln( ’Open wurde nicht redefiniert’ ) 
else 

Writeln( ’Open wurde redefiniert’ ); 


Bei der Auswertung des Ausdrucks awnd2T.open stellt der Compiler fest, daß 
Wnd2T keine Open-Methode definiert. Die Suche wird also von wna2tT aus nach 
oben begonnen. Für wnd2T.oOpen wird also im Endeffekt wndT.open eingesetzt, 
der Vergleich liefert TRUE. 


Der intelligente Linker des Turbo-Pascal-Systems behandelt auch redefinierte 
Methoden korrekt. Wenn durch die Redefinition die ursprüngliche Methode 
nicht mehr referenziert wird, wird sie aus dem Objektcode entfernt. Beachten 
Sie jedoch, daß auch die Anwendung des Adressoperators bereits eine Refe- 
renzierung ist. 


Nach dem gleichen Prinzip werden Referenzen auf Datenelemente abge- 
wickelt. Auch hier beginnt die Suche beim aktuellen Objekt und endet späte- 
stens in der obersten Hierarchiestufe. Da Datenelemente aber eindeutig sein 
müssen, kann es höchstens ein Datenelement mit dem geforderten Namen in 
der Suchkette geben. Die Redefinition von Daten ist nicht zulässig. 


6 Ein verbessertes 
Fenstersystem 


6.1 Aufgabenstellung 


Die bis jetzt entwickelten Routinen zur Bildschirmverwaltung verdienen ge- 
naugenommen noch nicht den Namen Fenstersystem. Es handelt sich eigent- 
lich nur um eine Erweiterung der Turbo-Pascal window-Routine, die die Wie- 
derherstellung des Bildschirminhaltes erlaubt. Zu einem richtigen Fenstersy- 
stem gehört aber mehr. 


In diesem Kapitel wird ein verbessertes Fenstersystem entwickelt, das neben 
Umrahmungen, Fensternamen und "Scrollbars" auch die Möglichkeit zur 
komfortablen Verwaltung mehrerer übereinander geöffneter Fenster bietet. 
Eine besondere Art von Fenstern sind die "Exploding Windows", bei denen 
durch eine geschickte Programmierung der Routinen zum Öffnen und Schlie- 
ßen der Eindruck eines sich dynamisch vergrößernden und verkleinernden 
Fensters entsteht. 


6.2 Implementierung 


Eine Möglichkeit zur Implementierung besteht in der Definition eines Daten- 
satzes, der alle erforderlichen Datenelemente enthält. Für die verschiedenen 
Funktionen des Fenstersystems werden dann einzelne Prozeduren entwickelt. 


Dieses Vorgehen findet man z.B. in den verschiedenen als Toolboxen ange- 
botenen Systemen. Es hat jedoch einen Nachteil: Es muß immer der gesamte 
Datensatz alloziert werden, auch wenn nur ein ganz einfaches Fenster erfor- 
derlich ist. Möchte man z.B. mit konventionellen Mitteln Fenster mit und 
ohne Scrollbars erzeugen können, gibt man der Open-Routine einen entspre- 
chenden bool’schen Parameter mit. Aber auch wenn dieser Parameter auf 
FALSE steht, werden Code und Daten für die Scrollbars trotzdem ins Pro- 
gramm mitaufgenommen. 
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Der einzige Weg, um die überflüssige Aufnahme von Code und Daten zu 
vermeiden, ist die Definition mehrerer paralleler Fenstersysteme. Die ver- 
schiedenen unabhängigen Daten und Prozeduren werden dann in verschie- 
denen Units oder in der gleichen Unit unter verschiedenen Namen angeord- 
net. 


Unter Verwendung der Vererbungstechnik kann eine wesentlich bessere Lö- 
sung gefunden werden. Ausgehend von einem Urfensterobjekt wird eine 
Objekthierarchie definiert, deren einzelne Elemente die verschiedenen Funk- 
tionalitätsstufen repräsentieren. 


Das Bild 6-1 zeigt die Hierarchie der geplanten Fensterobjekte. 


Objekte Eigenschaften 
Basic WndT Speicherung des Bildschirminhalts 
Speicherung der Cursorposition 
Fensterumrahmungen 


Exploding Windows 


Scroll Bars 


Bild 6-1 : Hierarchie der Fensterobjekte 


Die geforderten Eigenschaften werden wie folgt den verschiedenen Objekten 
der Hierarchie zugeordnet: 


BasicWndT 


BasicWndt sichert den Bildschirmbereich unter dem neuen Fenster. Die Spei- 
chertechnik ist so verbessert, daß nicht mehr der ganze Bildschirm, sondern 
nur noch der tatsächlich überschriebene Teil gesichert wird. Speichert vor 
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dem Öffnen die aktuelle Cursorposition, damit der Cursor nach dem Schlie- 
ßen wieder an diese Stelle positioniert werden kann. 


WndilT 


Wndit stellt zusätzlich zwei verschiedene Prozeduren bereit, um den Fenster- 
bereich zu umrahmen. Die beiden verschiedenen Rahmen können z.B. zur 
Unterscheidung zwischen dem aktuellen Ausgabefenster und anderen, da- 
runterliegenden Fenstern verwendet werden. Fenster können außerdem einen 
Namen erhalten. Der Name wird zentriert auf dem oberen Rahmen 
angezeigt. 


Wnd2T 


Die Prozeduren zum Öffnen und Schließen sind so umgestaltet, daß das Fen- 
ster von einem beliebigen Punkt auf dem Bildschirm ausgehend nach und 
nach aufgebaut bzw. zu diesem Punkt hin wieder abgebaut wird ("Exploding 
Windows"). 


Endgültiges Fenster 


Startpunkt 
Bild 6-2 : Exploding Windows 
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Exploding Windows werden meist von der Cursorposition im aktuellen Fen- 
ster aus geöffnet. Auf diese Weise kann optisch gut deutlichgemacht werden, 
daß sich das neue Fenster auf das Datenelement unter dem Zeiger bezieht. Ist 
z.B. ein Fenster mit dem Inhaltsverzeichnis einer Diskette angezeigt, kann 
von einem Verzeichnisnamen ausgehend ein Fenster mit dem Inhalt dieses 
Unterverzeichnisses geöffnet werden. 


Wnd3T 


Das Objekt wnd3t stellt Anzeigeflächen ("Scrollbars") am unteren und rechten 
Rand des Fensters bereit. Da ein Fenster oft nur einen Teil der anzuzeigen- 
den Daten aufnehmen kann, ist es sinnvoll, die Position des Fensters relativ 
zum Gesamttext anzuzeigen. Diese Funktion wird regelmäßig innerhalb von 
Texteditoren und Hilfesystemen benötigt. In Zusammenhang mit den Maus- 
funktionen verwendet man die Scrollbars außerdem zum Verändern dieser 
Relativposition, also zum "scrollen". 


Ausgehend von dieser Objekthierarchie kann man nun eine Instanz von genau 
dem Objekt erzeugen, das die erforderlichen Eigenschaften aufweist. Möchte 
man z.B. ein speicherresidentes Programm schreiben, das auf eine bestimmte 
Tastenkombination hin Datum und Uhrzeit anzeigt, ist ein ganz einfaches 
Fenster ausreichend. Hier kommt es darauf an, mit möglichst wenig Spei- 
cherplatz auszukommen. In einem professionellen Anwendungsprogramm 
dagegen wird man zugunsten einer komfortablen Benutzeroberfläche mehr 
Speicherplatz aufwenden können. 


Die Objekthierarchie kann nach oben beliebig erweitert werden. Es ist z.B. 
möglich, in einem abgeleiteten Fensterobjekt Routinen zur Mausbedienung 
der Fensterfunktionen wie scrollen, schließen, verschieben etc. zu definie- 
ren. Darauf aufbauend wiederum können verschiedene 
"Anwendungsfensterobjekte" definiert werden, also z.B. Texteditor, Menü- 
auswahl oder Hilfefenster. Diese weitergehenden Fensterobjekte sind zu- 
sammen mit Ton- und Farberweiterungen Thema eines weiteren Buches, das 
in der Reihe "Vieweg Software" im selben Verlag erscheinen wird.. 


6.3 Die Unit Window 


Die Objekte werden in einer Unit mit dem Namen window untergebracht. Ob- 
jektdeklarationen und global benötigte Deklarationen werden im Interfaceteil 
und die Implementierung der Objekte und lokalen Deklarationen im Imple- 
mentierungsteil der Unit angeordnet. 
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6.3.1 Der Interfaceteil 


Die Datei window enthält den Quelltext der Unit. Da der Implementierungsteil 
vollständig in Include-Dateien untergebracht ist, enthält die Datei window im 
wesentlichen den Interfaceteil der Unit. 


unit Window; 
interface 
uses Crt, General; 


{$1 W101.del > C-- Im InterfaceTeil gebrauchte Deklarationen } 


{$1 W102.dcl > €-- Fehlervariablen und Konstanten > 
[---------.-- BaseWndT ------------------------------- 40-7000 000000 > 
type BaseWndT = object 
WXMin, WXMax, 
WYMin, WYMax : integer; 
XCur, YCur : integer; {-- Cursorposition vor Oeffnen )} 
Status : WndStatusT; 
SavePp : LongArrayPT; {-- gesicherter Bildschirmbereich } 


w 


{-- Interne Variable 
ColCount, LineCount : integer; 
Amount : integer; 


procedure Make; 
procedure Kill; 


procedure Open( XMin, XMax, YMin, YMax : integer ); 
procedure Close; 


end; (-- BaseWndT } 


p: 
b 
x 
ä, 


object( BaseWndT ) 

WName : WNameT; 

procedure Open( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 
procedure SetStandard; 


procedure SetAlternate; 


end; {-- WndiT ) 
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type Wnd2T = object( WndiT ) 
WXStart, WYStart : integer; 


procedure Open( XMin, XMax, YMin, YMax : integer; Name : WNameT; 
XStart, YStart : integer ); 


procedure Close; 


end; {-- Wnd2T } 


type Wnd3T = object( Wnd2T ) 


WHorizontalScroll, 
WVerticalScroll : integer; 


procedure SetHorizontalScroll( Percent : integer ); 
procedure SetVerticalScroll( Percent : integer ); 


end; {-- Wnd3T } 


implementation 


{$I W111.del > (-- ScreenT } 
{$I Ww112.del > {-- Konstanten fuer Rahmen } 


{$I W100 > {-- Methoden BaseWndT } 
{$1 W101 > (-- Methoden Wnd1T } 
{$1 W102 > {-- Methoden Wnd2T > 
{$1 W103 } {-- Methoden wWnd3T } 
begin 

ScreenPp:= ptr( GetScreenBase, 0 ); 

end. 


6.3.2 Deklarationen im Interface- und 
Implementierungsteil 


Nach dem Unit-Konzept müssen alle Datendeklarationen, auf die ein Nutzer 
der Unit Zugriff haben soll, im Interfaceteil angeordnet werden. Deklaratio- 
nen, die dagegen nur innerhalb der Unit verwendet werden, sollen im Im- 
plementierungsteil untergebracht werden. Leider läßt sich diese Trennung 
zwischen Interface und Implementierung bei Verwendung von Objekten nicht 
immer in der gewünschten Konsequenz durchhalten. 


So ist es z.B. erforderlich, die Typen wndstatust und LongArraypt im Inter- 
faceteil zu deklarieren, da sie in der Objektdefinition von Basewndt gebraucht 
werden. Damit werden diese Typen gleichzeitig exportiert, d.h. der Nutzer 
der Unit kann diese Typen ebenfalls verwenden, obwohl sie eigentlich nur 
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zum internen Gebrauch innerhalb der Unit vorgesehen sind. Alle Deklaratio- 
nen, die eigentlich intern sind, aber trotzdem im Interfaceteil der Unit aufge- 
führt werden müssen, sind in der Datei W101.dcl zusammengefaßt. 


{-- Bezeichnet den Zustand eines Fensters. Sinnvoll fuer 
erweiterte Fehlerpruefungen --) 
type WndStatusT 


= ( closed, {-- kein Speicher zugewiesen }) 
active ); {-- Fenster offen > 

{-- LongArrayT erlaubt die Interpretation eines Speicherbereiches als 
Folge von Einzelzeichen --) 


array[ 1..MaxInt ] of char; 
*LongArrayT; 


type LongArrayT 
LongArrayPT 


{-- WNameT aus Speicherplatzgruenden eingefuehrt --) 


type WNameT = string[ 10]; 


In diesem speziellen Fall könnte man einen Teil des Problems umgehen, in- 
dem man die Variable saver als allgemeinen Zeiger definiert. LongAarrayT 
könnte dann in den Implementierungsteil der Unit verlegt werden. savep 
könnte dann aber nur mit Hilfe expliziter Typumwandlungen verwendet wer- 
den. Ebenso könnte man status z.B. als byte deklarieren und so wndstatust in 
den Implementierungsteil verlagern. Im allgemeinen Falle läuft dies darauf 
hinaus, im Datenbereich eines Objekts nur den nötigen Speicher zu deklarie- 
ren und die eigentlichen Datentypen zur Interpretation dieses Speichers erst 
im Implementierungsteil zu definieren. Obwohl dadurch explizite Typum- 
wandlungen beim Zugriff auf Daten eines Objekts erforderlich werden, ist 
diese Methode in der Regel vorzuziehen, da die objektinterne Interpretation 
der Daten versteckt bleiben kann. Hier wäre eine Aufteilungsmöglichkeit des 
Datenbereiches eines Objekts in einen globalen und einen lokalen Teil wün- 
schenswert. 


6.3.3 Der Zugriff auf den Bildschirmspeicher 


Die Datei Wi1ll.dcl enthält Deklarationen zum direkten Zugriff auf den 
Bildschirmspeicher. 
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{-- Interpretation eines Hauptspeicherbereiches als Bildschirmspeicher } 


80; {-- Spalten pro Zeile } 
25; {-- Bildschirmzeilen } 


const ScrColumnst 
ScrLinesC 


type ScrCharT = record 
Ch : char; {-- Das eigentliche Zeichen } 
Attr : byte; {-- Attribut des Zeichens } 


end; (-- ScrCharT } 


array[l 1..ScrColumnsc ] of ScrCharT; 


type ScrLineT 


"ScreenT; 
array[ 1..ScrLinesC ] of ScrLineT; 


type ScreenPT 
ScreenT 


{-- ScreenP zeigt auf Hardwarebildschirm. Wird im Initialisierungsteil 
von Window initialisiert --} 


var ScreenP : ScreenPT; 


Zunächst wird der Typ scrchart definiert, der ein Zeichen im Bildschirmspei- 
cher repräsentiert. Ein solches Zeichen besteht aus dem eigentlichen Zeichen 
selber sowie dem Attribut (unter anderem Farbe und Intensität) des Zeichens. 
Screent wird mit einer vorgegebenen Spalten- und Zeilenzahl als Array aus 
diesem Grundelement aufgebaut. Nachdem screenp im Initialisierungsteil der 
Unit mit Hilfe der bekannten Prozedur GetscreenBase auf den Anfang des Bild- 
schirmspeichers gesetzt wurde, kann auf den Bildschirminhalt in der ge- 
wohnten Weise mit Zeilen- und Spaltennummer zugegriffen werden. 
Screenp*[ 10, 12 1.ch ist z.B. das Zeichen auf dem Bildschirm in Zeile 10, 
Spalte 12. Die Methode open verwendet screenpt, um Daten vom Bildschirm 
einzulesen. Für die Ausgabe werden weiterhin die Standardroutinen write 
bzw. writeln verwendet. Steht die Variable Directvideo der Unit crt auf TRUE 
(Standardeinstellung), erfolgt die Bildschirmausgabe von Turbo-Pascal eben- 
falls unter Umgehung der BIOS-Routinen direkt in den Bildschirmspeicher. 
Es würde daher nichts gewonnen, screenpt auch zur Ausgabe zu verwenden. 
Im Gegenteil, denn die Standardprozeduren write und writeln bieten hervor- 
ragende Formatierungsmöglichkeiten für Strings und numerische Daten so- 
wie den Vorteil einer variablen Anzahl Parameter. Man muß jedoch beach- 
ten, daß sich Ausgaben über write und writeln, Cursorpositionierungen mit 
GotoxY etc. auf ein definiertes Fenster beziehen, der Zugriff über screent je- 
doch immer auf den Gesamtbildschirm. Verwendet man beide Methoden 
parallel, ist eine Umrechnung erforderlich. 


Die Konstanten serColumsc und ScrLinesc definieren die Größe des Bild- 
schirms. Für andere Modi wie z.B. den 43 Zeilenmodus bei EGA oder 50 
Zeilenmodus bei VGA Adaptern können diese Konstanten entsprechend an- 
gepaßt werden. 
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Der Typ screent wird in den Methoden der einzelnen Objekte verwendet. Er 
wird in keinem Objektdatenbereich gebraucht und kann deshalb im Imple- 
mentierungsteil der Unit deklariert werden. 


6.3.4 Das Abfangen von Fehlern 


In allen Routinen werden Prüfungen der übergebenen Parameter auf Zuläs- 
sigkeit durchgeführt. Liegen Werte nicht im zulässigen Wertebereich, wird 
die Routine nicht ausgeführt. Die Objektvariable status gibt an, ob das Fen- 
ster geöffnet oder nicht geöffnet ist. Mehrfaches Offnen oder Schließen kann 
so als Fehler erkannt werden. Bevor Speicher vom Heap angefordert wird, 
wird grundsätzlich geprüft, ob noch genügend Speicher frei ist. Der Turbo- 
Pascal Laufzeitfehler 203: Heap Overflow Error kann deshalb nicht auftreten. 


Die Unit exportiert die Variablen undok und wnderror. Die bool’sche Variable 
Wndok zeigt an, ob die letzte Operation erfolgreich war oder ob ein Fehler auf- 
getreten ist. Wenn wndok false ist, gibt wnderror den Fehlertyp an. Zur Inter- 
pretation des Wertes in wndError sind in der Datei W102.del Konstanten defi- 
niert, die ebenfalls exportiert werden. 


var WndOK : boolean; {-- true : kein Fehler } 
WndError : integer; {-- Fehlernummer falls WndoK = false } 


const WndWrongParam 
WndTooSmall 
WndNoMem 
WndWrongStat 
WndWrongStart 
WndWrongScroll 
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6.4 Verwendung des Kellerspeichers 


Durch Erzeugen mehrerer Instanzen können mehrere Fenster auf dem Bild- 
schirm übereinander oder nebeneinander geöffnet werden. Da das Urfenster- 
objekt als Nachfolger von stackeimt definiert wurde, kann der Kellerspeicher 
zur Ablage der verschiedenen Instanzen verwendet werden. 


Das folgende Beispiel öffnet drei Fenster und schließt sie in der richtigen 
Reihenfolge wieder: 
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uses crt, Window, StackU; 


type Wnd3PT = "Wnd3T; 


var WP : Wnd3PT; 
Stack : StackT; 
I : integer; 
begin 


Stack.Make; 
{-- Oeffnen von drei Fenstern --) 


for 1:=5 to 7 do 
begin 
New( WP ); 
WP” „Make; 
WP*.Open( 2*I, 2*1+10, 2*1, 2*1+5, 'Test’, 2, 2); 
if Stack.Push( WP ) then; 
ClrScr; 
Delay( 100 ); 
end; 


Delay( 1000 ); 
{-- Schliessen in umgekehrter Reihenfolge --} 


WP:= Wnd3PT( Stack.Pop ); 
while WP <> nil do 
with WP* do 

begin 

Close; 

Kill; 

Dispose( WP ); 

WP:= Wnd3PT( Stack.Pop ); 

end; 


Stack.Kill; 


end. 


In diesem Beispiel ist nicht für jede Instanz eine Variable erforderlich, da der 
Kellerspeicher die Aufgabe der Speicherung übernimmt. Auf diese Weise 
können beliebig viele Fenster erzeugt und verwaltet werden. Die Notwendig- 
keit der expliziten Beförderung des von pop zurückgelieferten Zeigers macht 
die Deklaration des Typs wna3Ppt erforderlich. Die Beförderung kann nicht mit 
wnd3T selber durchgeführt werden, die Anweisung 


WP:= *Wnd3T( Stack.Pop ); 


ist unzulässig. Es empfiehlt sich also, bei der Entwicklung von Objekten die 
zugehörigen Zeigertypen gleich mitzudeklarieren. 
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Die Unit stacku zeigt eine alternative Möglichkeit der Fehlerbehandlung. 
Während in window spezielle Variablen zur Übergabe des Fehlerstatus ver- 
wendet werden, erfolgt die Rückgabe des Status in stacku als Ergebniswert 
der Methoden. stackTt.push liefert TRUE oder FALSE, je nachdem, ob die 
Operation erfolgreich war oder nicht. Diese aus der C-Programmierung ge- 
läufige Art hat jedoch einige Nachteile. In Pascal kann - im Gegensatz zu C - 
eine Funktion nicht wie eine Prozedur aufgerufen werden, d.h. eine Funktion 
muß immer in einem Ausdruck stehen. Möchte man also wie im obigen Bei- 
spiel auf eine Fehlerbehandlung verzichten, muß der Rückgabewert von 
StackT.Push trotzdem einer Variablen zugewiesen oder sonstwie behandelt 
werden. 


Ein weiterer Vorteil der Kommunikation über eine Variable liegt in der hö- 
heren Flexibilität. wndok kann nämlich im Zuge der Entwicklung der Unit 
window auch als Funktion formuliert werden, ohne daß Anwendungspro- 
gramme geändert werden müssen. Eine solche Änderung einer Variablen in 
eine Funktion könnte verwendet werden, um bei der Abfrage des Fehlersta- 
tus zusätzliche Arbeiten auszuführen. 


Möchte man unterschiedliche Fenstertypen verwalten, entsteht das zusätzli- 
che Problem, zu welchem Typ der von stackT.Pop zurückgelieferte Zeiger be- 
fördert werden soll. Hier bleibt (bis zum nächsten Kapitel) nur die in der 
Fallstudie Kellerspeicher in Abschnitt 5.12 vorgestellte Einführung einer zu- 
sätzlichen Statusvariablen in den Datenbereich aller Objekte. Diese Variable 
wird dann von der Methode Make entsprechend gesetzt und kann dann zur 
"Beförderungsentscheidung" - z.B. in einer case-Anweisung - verwendet 
werden. Make kann nun nicht mehr vererbt werden, sondern muß für alle Ob- 
jekte implementiert werden. 


Mit dieser zusätzlichen Statusvariablen sowie den Zeigertypen für die Fen- 
sterobjekte erhält die Unit window nun folgende Form: 


unit Window; 
interface 
uses Crt, General, StackU; 


{$1I W101.dcl > {-- Im InterfaceTeil gebrauchte Deklarationen } 


{$I W102.dcl )3 €-- Fehlervariablen und Konstanten > 
[7-7 ----...-- PreBaseWndT -------------------------------- 740-0000 > 
type PreBaseWndT = object( StackElmT ) 

ObjectType : ( BaseWnd, Wndi1, Wnd2, Wnd3 ); 


end; {-- PreBaseWndT } 


type PreBaseWndPT = “PreBaseWndT; 
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type BaseWndT 
WXMin, WXMax, 


object( PreBaseWndT ) 


WYMin, WYMax : integer; 

XCur, YCur : integer; (-- Cursorposition vor Oeffnen )} 
Status : WndStatusT; 

SaveP : LongArrayPT; (-- gesicherter Bildschirmbereich } 


ColCount, LineCount : integer; 
Amount : integer; 


procedure Make; 
procedure Kill; 


procedure Open( XMin, XMax, YMin, YMax : integer ); 
procedure Close; 


end; {-- BaseWndT } 


type BaseWndPT = *BaseWndT; 
E----------- WndIT _-------------- HH 00000 Ener } 
type WndiT = object( BaseWndT ) 

WName : WNameT; 


procedure Make; 

procedure Open( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 
procedure SetStandard; 

procedure SetAlternate; 


end; {-- WndiT } 


type WndiPT = *WndiT; 
{----------- Wnd2T === ----------- 4-40 0000000 mann }) 
type Wnd2T = object( WndIT ) 

WXStart, WYStart : integer; 


procedure Make; 

procedure Open( XMin, XMax, YMin, YMax : integer; Name : WNameT; 
XStart, YStart : integer ); 

procedure Close; 


end; {-- Wnd2T } 


type Wnd2PT = *Wnd2T; 
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type Wnd3T = object( Wnd2T ) 


WHorizontalScroll, 
WVerticalScroll : integer; 


procedure Make; 
procedure SetHorizontalScroll( Percent : integer ); 
procedure SetVerticalScroll( Percent : integer ); 
end; {-- Wnd3T } 

type Wnd3PT = *Wnd3T; 


implementation 


($1I W111.del > {-- ScreenT } 
{$I W112.del > {-- Konstanten fuer Rahmen und Scrollbars } 


{$1 W100 > {-- Methoden BaseWndT } 
{$I W101 > {-- Methoden Wnd1T } 
{$1 W102 } {-- Methoden Wnd2T } 
{$I W103 > {-- Methoden Wnd3T } 
begin 

ScreenPf:= ptr( GetScreenBase, 0 ); 

end. 


Die Implementierung von Make wird so geändert, daß die neue Variable 
ObjectType richtig gesetzt wird: 


Datei W100 


procedure BaseWndT .Make; 
begin 

Status:= closed; 

WndOK:= true; 
ObjectType:= BaseWnd; 
end; {-- Make } 


Datei W101 


procedure Wnd1T.Make; 
begin 

BaseWndT „Make; 
ObjectType:= Wnd1; 
end; {-- Make } 
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Datei W102 


procedure Wnd2T .Make; 
begin 

Wnd1T.Make; 
ObjectType:= Wnd2; 
end; (-- Make } 


Datei W103 


procedure Wnd3T .Make; 
begin 

Wnd2T „Make; 
ObjectType:= Wnd3; 
end; (-- Make ) 


Ein Beispielprogramm zum richtigen Öffnen und Schließen von drei ver- 
schiedenen Fenstern könnte etwa so aussehen: 


uses Crt, Window, StackU; 


var WP : StackElmPT; 
BaseWP : BaseWndPT; 
WiP : Wnd1PT; 
W2P : Wnd2PT; 
W3P : Wnd3PT; 
Stack : StackT; 
I : integer; 
begin 


Writeln( MemAvail ); 
Stack .Make; 
{-- Oeffnen von drei verschiedenen Fenstern ---) 


New( W2P ); 

W2P” „Make; 

wW2P*.Open( 10, 20, 10, 15, 'Wnd2T’, 2, 2 ); 
if Stack.Push( W2P ) then; 

ClrScr; 

Delay( 100 ); 


New(C WIP ); 

W1P” .Make; 

WiP*.Open( 12, 22, 12, 17, 'WndiT’ ); 
if Stack.Push( WiP ) then; 

ClrScr; 

Delay( 100 ); 


New( WOP ); 

W2P” „Make; 

W2P”.Open( 14, 24, 14, 19, 'Wnd2T’, 2, 2 ); 
if Stack.Push( W2P ) then; 
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ClrScr; 
Delay( 100 ); 


Delay( 1000 ); 
{-- Schliessen in umgekehrter Reihenfolge --) 


WP:= Stack.Pop; 
while WP <> nil do 
begin 


case PreBaseWndPT( WP )*.ObjectType of 


BaseWnd : begin 
BaseWP:= BaseWndPT( WP ); 
BaseWP”“.Close; 
BaseWP”“ .Kill; 
Dispose( BaseWP ); 
end; 


Wnd1 : begin 
WIP:= WndIPT(C WP ); 
WiP”.Close; 
WiP*.Kill; 
Dispose( WIP ); 
end; 


Wnd2 : begin 
W2P:= Wnd2PT( WP ); 
W2P”.Close; 
w2Pp”.Kill; 
Dispose( W2P ); 
end; 


Wnd3 : begin 
W3P:= Wnd3PT( WP ); 
W3P”.Close; 
W3P”.Kill; 
Dispose( W3P ); 
end; 


end; (-- case } 

Delay( 100 ); 

WP:= Stack.Pop; 

end; (-- while W <> nil } 
Stack.Kill; 
Writeln( MemAvail ); 


end. 


In dieser so geänderten Implementierung der Fensterobjekte treten die Nach- 
teile der "Markierung" der verschiedenen Objekte durch eine spezielle Va- 
riable deutlich zutage. Es ist insbesondere die fehlende Erweiterbarkeit, die 
diesen Ansatz so ungeeignet macht. So muß man sich bereits bei der Dekla- 


6.4 Verwendung des Kellerspeichers 77 


ration von PreBasewndt überlegen, welche Objekte in der Hierarchie überhaupt 
verwendet werden sollen, denn für jedes Objekt muß ein Element im Auf- 
zählungstyp vorgesehen werden. Das kann man noch durch eine unspezifi- 
zierte Aufzählungsvariable (z.B. byte Oder integer) umgehen, aber spätestens 
im Beispielprogramm muß man sich festlegen. Dort muß nämlich für jedes 
mögliche Fensterobjekt auch eine zugeordnete Auswahl in der case-Anwei- 
sung vorgesehen werden. Für jeden Aufruf einer Methode ist dann eine sol- 
che case-Anweisung erforderlich. Im nächsten Kapitel werden wir Techniken 
kennenlernen, um die korrekte Beförderung einer Variablen durch Turbo- 
Pascal selber durchführen zu lassen. Explizite Beförderungen und damit zu- 
sammenhängende case-Anweisungen können dann vermieden werden. 


6.4.1 Das Objekt WndStackT 


Da in den meisten Anwendungsprogrammen nicht nur ein Fenster gebraucht 
wird, ist es sinnvoll, die zum Öffnen und Schließen mehrerer Fenster ge- 
brauchten Arbeitsschritte als Prozeduren zu formulieren und ebenfalls in die 
Unit window mit aufzunehmen. 


Das folgende Objekt wndstackt erfüllt diese Aufgabe. Es ist als Nachfolger 
von Stackt definiert. 


type WndStackT = object( StackT ) 
ActiveWP : PreBaseWndPT; 
procedure Make; 
procedure OpenBaseWnd( XMin, XMax, YMin, YMax : integer ); 


procedure OpenWndi( XMin, XMax, YMin, YMax : integer; 
Name : WNameT ); 


procedure OpenwWnd2( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


procedure Openwnd3( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


procedure CloseWnd; 
end; (-- WndStackT } 


type WndStackPT = “WndStackT; 


Die Variable Activewp ist ein Zeiger auf das aktuelle Fenster. Das Anwen- 
dungsprogramm kann über diesen Zeiger auf Daten und Methoden des aktu- 
ellen Fensters zugreifen. Die zugehörige Implementierung ist in der Include- 
datei W110 abgelegt. 
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procedure WndStackT .Make; 
begin 

StackT.Make; 

ActiveWP:= nil; 

end; {-- Make ) 


procedure WndStackT.OpenBaseWnd( XMin, XMax, YMin, YMax : 


var BaseWP : BaseWndPT; 


begin 
New( BaseWP ); 
BaseWP” „Make; 
BaseWP“.Open( XMin, XMax, YMin, YMax ); 
if WndOK then 
begin 
ActiveWP:= BaseWP; 
if not Push( BaseWP ) then 
begin 
WndoK:= false; 
WndError:= WndStackFull; 
end; 
end; 


end; {-- OpenBaseWnd } 


procedure WndStackT.OpenWnd1( XMin, XMax, YMin, YMax : 


Name : WNameT ); 
var WiP : Wnd1PT; 


begin _ 
New( WiP ); 
W1P” .Make; 
WiP*.Open( XMin, XMax, YMin, YMax, Name ); 
if WndOK then 
begin 
ActiveWP:= WIP; 
if not Push( WIP ) then 
begin 
WndOoK:= false; 
WndError:= WndStackFull; 
end; 
end; 


end; {-- OpenWndi } 


integer ); 


integer; 
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procedure WndStackT.OpenWnd2( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


var W2P : Wnd2PT; 


begin 
New( W2P ); 
W2P” „Make; 
W2P”*.Open( XMin, XMax, YMin, YMax, Name, XStart, YStart ); 
if WndOK then 
begin 
ActiveWP:= W2P; 
if not Push( W2P ) then 
begin 
WndOK:= false; 
WndError:= WndStackFull; 
end; 
end; 


end; {-- OpenWnd2 } 


procedure WndStackT.OpenWnd3( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


var W3P : Wnd3PT; 


begin 
New( W3P ); 
W3P” .Make; 
W3P*.Open( XMin, XMax, YMin, YMax, Name, XStart, YStart ); 
if WndOK then 
begin 
ActiveWP:= W3P; 
if not Push( W3P ) then 
begin 
WndOK:= false; 
WndError:= WndStackFull; 
end; 
end; 


end; {-- OpenWnd3 } 
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procedure WndStackT.CloseWnd; 


var WP : StackElmPT; 
BaseWP : BaseWndPT; 
WiP : WndiPT; 
W2P : Wned2PT; 
W3P : Wnd3PT; 
begin 


WndoK:= false; 


WP:= Pop; 
if W = nil then 
begin 
WndError:= WndStackEmpty; 
Exit; 
end; 


case PreBaseWndPT( WP )”".ObjectType of 


BaseWnd : begin 
BaseWP:= BaseWndPT( WP ); 
BaseWP“.Close; if not WndOK then Exit; 
BaseWP“.Kill; if not WndOK then Exit; 
Dispose( BaseWP ); 
end; 


Wnd1 : begin 
W1P:= WndiPT( WP ); 
WiP”.Close; if not WndOK then Exit; 
WiP*.Kill; if not WndOK then Exit; 
Dispose( WIP ); 
end; 


Wnd2 : begin 
W2P:= Wnd2PT(C WP ); 
W2P“.Close; if not WndOK then Exit; 
W2P”“.Kill; if not WndOK then Exit; 
Dispose( W2P ); 
end; 


Wnd3 ı begin 
W3P:= Wnd3PTC WP ); 
W3P”.Close; if not WndOK then Exit; 
W3P”.Kill; if not WndOK then Exit; 
Dispose( W3P ); 
end; 


end;{-- case } 
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(-- ActiveWP mit dem obersten Fenster besetzten oder nil --} 


WP:= Pop; 
if WP <> nil then 

if Push( WP ) then; 
ActiveWP:= WP; 


WndOK:= true; 
end; (-- Close } 


Zur richtigen Funktion müssen noch die Fehlerkonstanten in der Datei 
W102.dcl um wndstackFull und WndStackEmpty erweitert werden: 


var WndOK : boolean; {-- true : kein Fehler } 
WndError : integer; {-- Fehlernummer falls WndOK = false } 


const WndWrongParam 
WndTooSmall 
WndNoMem 
WndWrongStat 
WndWrongStart 
WndWrongScroll 


ı mm mn U 
ON Avrww-_ 
ma wa ng wo “oa 


=. 


WndStackEmpty 
WndStackFull 


na 


a 


Das folgende Anwendungsprogramm Öffnet und schließt drei Fenster mit 
Hilfe des neuen Objekts wnastackT. 


uses Crt, Window, StackU; 

var WndStack : WndStackT; 

begin 

WndStack .Make; 

{-- Oeffnen von drei verschiedenen Fenstern ---) 
WndStack.OpenWnd2( 10, 20, 10, 15, 'Wnd2T', 2, 2 ); 
ClrScr; 

Delay( 100 ); 

WndStack.OpenWndi( 12, 22, 12, 17, 'Wndi1T’ ); 
ClrScr; 

Delay( 100 ); 

WndStack.OpenWnd3( 14, 24, 14, 19, 'Wnd3T’, 2, 2 ); 
ClrScr; 

Wnd3PT( WndStack.ActiveWP )“.SetHorizontalScroll( 30 ); 


Delay( 1000 ); 
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{-- Schliessen in umgekehrter Reihenfolge --) 


repeat 
WndStack.CloseWnd; 
Delay( 100 ); 

until WndOK = false; 


WndStack.Kill; 


end. 


Da das Anwendungsprogramm "weiß", daß das letzte geöffnete Fenster vom 
Typ wnd3t ist, kann Activewp gefahrlos zum Aufruf von SetHorizontalScroll 
verwendet werden. Beachten Sie bitte, daß die Beförderung von ActivewPp 
syntaktisch z.B. auch dann möglich wäre, wenn die Variable auf eine Instanz 
von wndit zeigt. Der Aufruf von SetHorizontalscroll würde dann Daten außer- 
halb von und1r überschreiben. 


6.4.2 Verbesserte Fehlerbehandlung 


Im Fehlerfall liefern die Routinen des Fenstersystems in den Variablen wndok 
und wnderror entsprechende Werte an das Anwenderprogramm zurück. Das 
Anwenderprogramm sollte daher nach Aufruf einer Methode grundsätzlich 
die Variable wndok prüfen und im Fehlerfalle entsprechende Schritte durch- 
führen. Meist ist es sinnvoll, das Programm abzubrechen, z.B. wenn Fen- 
sterkoordinaten im Anwendungsprogramm fest definiert und open mit dem 
Fehlercode wndwrongparam abbricht. In anderen Fällen reicht eine Meldung an 
den Benutzer aus, z.B. dann, wenn vom Benutzer eingegebene Fensterkoor- 
dinaten nicht im zulässigen Bereich liegen. 


Die in diesem Abschnitt entwickelte Erweiterung der Fehlerbehandlung im- 
plementiert eine Fehlerbehandlungsroutine, die die beiden allgemeinen Fälle 
"Meldung" und "Meldung und Abbruch" abhandelt. Für welche Fehlerarten 
eine der beiden Möglichkeiten aufgerufen werden soll, kann in den globalen 
Variablen Msgcodeset und HaltCodeset spezifiziert werden. Diese beiden Vari- 
ablen werden im Initialisierungsteil der Unit so vorbesetzt, daß alle Fehler- 
situationen mit einer Fehlermeldung zum Abbruch führen. 


Der Aufruf der Fehlerbehandlungsroutine erfolgt in den einzelnen Methoden 
an der Stelle, an der früher die Variable wnderror gesetzt wurde. An das An- 
wenderprogramm wird nur dann ein Fehler zurückgeliefert, wenn der Fehler 
nicht schon durch die interne Routine abgefangen wurde. 


Da Fehler nun teilweise vom System selber, teilweise aber auch vom Benut- 
zer abgehandelt werden können, besteht die Gefahr, daß Fehler gar nicht ab- 
gefangen werden. Alle Methoden der Fensterobjekte und des Objekts 
Wndstackt werden deshalb so erweitert, daß sie nur dann ihre Funktion verse- 
hen, wenn wndok beim Aufruf TRUE ist. Ist dies nicht der Fall, wird der 
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Fehlercode wndnotok zurückgegeben. Eine im Anwenderprogramm implemen- 
tierte Fehlerbehandlungsroutine muß deshalb nach Bearbeitung des Fehlers 
die Variable undok wieder auf TRUE setzen. 


Zur Implementierung der erweiterten Fehlerprüfung wird die Routine 
Wndcheck verwendet. Da sowohl die Fensterobjekte als auch wndstackt diese 
Routine verwenden, kann sie nicht als eine Methode eines dieser Objekte de- 
klariert werden. Analog dazu können die Variablen Msgcodeset und HaltCodeset 
nicht im Datenbereich der Objekte deklariert werden. Dies wäre nur dann 
möglich, wenn wnastackt und die Fensterobjekte einen gemeinsamen Vorgän- 
ger hätten. Stattdessen wird wnacheck als gewöhnliche Funktion zusammen mit 
der Prozedur sg in der Datei W120 implementiert. 


procedure msg( ErrorCode : byte ); 
begin 


case ErrorCode of 


WndWrongParam : WritelnC '’Falsche Parameter’ ); 
WndTooSmall : Writeln( ’Fenster zu klein’ ); 
WndNoMem : Writeln( ’Kein Speicher mehr’ ); 
WndWrongStat : Writeln( ’Falscher Status’ ); 
WndWrongStart : Writeln( ’Falsche Startwerte’ ); 
WndWrongScroll : WritelnC ’Falsche Scrollbars’ ); 
WndStackEmpty : Writeln( ’Keine offenen Fenster mehr’ ); 
WndStackFull : Writeln( ’Kein Platz mehr auf Stack’ ); 


end; {-- case } 
end; {-- msg } 


function WndCheck( ErrorCode : byte ) : boolean; 


begin 
WndError:= ErrorCode; 


if ErrorCode in MsgCodeSet then 


begin 
Msg( ErrorCode ); 
WndOK:= true; 
end 
else 


WndOK:= false; 


if ErrorCode in HaltCodeSet then 
Halt( 1 ); 


WndCheck:= not WndOK; 
end; {-- WndCheck } 


Die zugehörigen Variablen Msgcodeset und HaltCodeset sind in W101.dcl defi- 
niert. 


type ErrorCodeSetT = set of byte; 
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var MsgCodeSet, HaltCodeSet : ErrorCodeSetT; 


Die neudefinierte Fehlerkonstante wndnotok wird in W102.dcl untegebracht. 


const WndNotCK = 9; 


Das Fenstersystem in seiner jetzigen Form ist noch einmal vollständig in An- 
hang aufgelistet. 


Dieser Ausflug in die praktische Programmierung mit objektorientierten 
Techniken läßt einige Probleme und Unschönheiten erkennen. Insbesondere 
der Zwang zur expliziten Beförderung von Instanzen, das heißt zur expliziten 
Typumwandlung von Variablen ist besonders störend. Das nächste Kapitel 
zeigt unter anderem, wie dieses Manko beseitigt werden kann. 
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7 Virtuelle Methoden 


7.1 Ein ganz neues Konzept 


Stellen Sie sich vor, Sie haben das im letzten Kapitel entwickelte Fenstersy- 
stem in Unit-Form zur Verfügung, um es in einer größeren Programment- 
wicklung zu verwenden. Da der Quelltext nicht verfügbar ist, kann auch die 
Funktionalität der Unit nicht mehr geändert werden. Je mehr solcher Units in 
der Programmentwicklung verwendet werden, um so mehr sieht sich der 
Programmentwickler Zwängen ausgesetzt, genau die vordefinierten Schnitt- 
stellen dieser Unit einzuhalten. Das Problem liegt darin, daß der Entwickler 
der Unit nicht weiß, für welche Anwendung seine Unit verwendet werden 
wird. Ein oft beschrittener Weg zur Milderung dieses Problems ist, für mög- 
lichst viele vorhersehbare Anwendungsfälle Routinen oder besondere Para- 
meter vorzusehen. Damit wird zwar die potentielle Verwendungsbreite er- 
höht, aber gleichzeitig steigt die Komplexität der Schnittstelle zum Anwen- 
derprogramm unerwünscht stark an. 


Ein eleganterer Weg wäre, wenn man einzelne Funktionen der Unit an seine 
eigenen Bedürfnisse anpassen, den Rest aber unverändert übernehmen 
könnte. Die Technik der Vererbung bietet hier einige Möglichkeiten. Durch 
Definition von abgeleiteten Objekten können Methoden wahlweise über- 
nommen oder aber neu definiert werden. Das im letzten Kapitel entwickelte 
Fenstersystem zeigt ein Beispiel für diese Einsatzmöglichkeit auf. So ist es 
z.B. möglich, auf wnd2t aufbauend eigene Fensterobjekte zu definieren und 
diese auch mit dem Kellerspeicher zu verwalten. Ebenso kann von wndstackT 
ein weiteres Objekt abgeleitet werden, das diese Verwaltungsaufgaben über- 
nimmt. 


Es ist jedoch nicht möglich, einmal festgelegte Funktionen zu ändern. So 
wäre es z.B. praktisch, wenn wndstackT.Closewnd auch diese neuen, erst im 
Anwenderprogramm definierten Fenster richtig schließen könnte. Dazu 
müßte die case-Anweisung in Closewnd um diesen neuen Typ erweitert wer- 
den. Da der Quelltext nicht verfügbar ist, bleibt als einzige Möglichkeit, eine 
eigene Closewnd-Routine zu schreiben. 


Objektorientierte Programmierung mit virtuellen Methoden ermöglicht die 
Überwindung solcher Einschränkungen. In unserem Fall kann die Unit window 
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so konstruiert werden, daß auch nachfolgende, erst im Anwenderprogramm 
definierte Fensterobjekte mit wndstackt verwaltet werden können, ohne 
WndStackt modifizieren zu müssen. 


Das wirklich Neue an virtuellen Methoden zeigt ein weiteres Beispiel. Die 
Fehlerbehandlungsroutinen in der Unit window ermöglichen die Ausgabe einer 
Meldung, den Abbruch des Programms oder wahlweise die Rückgabe eines 
Fehlercodes an das Anwenderprogramm. Ist der Nutzer mit der Leistung der 
bereitgestellten Fehlerbehandlung nicht zufrieden, muß er die Fehlersituatio- 
nen manuell im Programm nach seinen Wünschen behandeln. Über Variablen 
teilt der Nutzer mit, welche Fehlersituationen durch das Fenstersystem selber 
und welche durch das Anwenderprogramm abgefangen werden sollen. 


Objektorientierte Programmierung mit virtuellen Methoden bietet hier eine 
elegante Alternative. Es ist möglich, im Anwenderprogramm eine Fehlerbe- 
handlungsroutine zu schreiben, und zwar so, daß auch die bereits übersetzten 
Routinen in window im Fehlerfall diese neue Prozedur aufrufen. 


Mit diesem Wissen kann der Entwickler von window auf die Unterscheidung 
zwischen Fehlern, die vom Fenstersystem selber abgefangen und solchen, die 
an das Anwenderprogramm gemeldet werden sollen, verzichten. Er imple- 
mentiertt nur noch eine Fehlerbehandlungsroutine, die in jeder 
Fehlersituation aufgerufen wird. Die durchgeführte Fehlerbehandlung kann 
dann sehr einfach sein, sie kann sich z.B. auf den Ausdruck einer Meldung 
beschränken. Möchte der Nutzer dieser Unit seine eigene Fehlerbehandlung 
implementieren, schreibt er einfach seine eigene Routine! Turbo-Pascal stellt 
sicher, daß die neue, erst im Anwenderprogramm definierte Prozedur auch 
von den Routinen in der Unit window aufgerufen wird. 


Mit virtuellen Methoden kann man also erreichen, daß eine bereits übersetzte 
Unit Prozeduren aufruft, die dem Compiler zu Übersetzungszeit noch gar 
nicht bekannt sind. 


7.2 Ein Beispiel 


Betrachten wir zum Verständnis dieser erstaunlichen Tatsache ein Beispiel. 
Die beiden Objekte at und gr definieren jeweils eine Prozedur poıt. Br ist als 
Nachfolger von ar definiert. 
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type AT = object 


AVar : Integer; 
procedure Dolt; 


end; (-- AT } 

type APT = "AT; 

type BT = object( AT ) 
BVar : integer; 


procedure Dolt; 

end; (-- BT ) 
type BPT = ’BT; 
procedure AT.Dolt; 
begin 


Writeln( ’Hier ist AT.Dolt’ ); 
end; {-- Dolt ) 


procedure BT.Dolt; 

begin 

Writeln( ’Hier ist BT.Dolt’ ); 
end; {-- Dolt )} 


var AP : APT; 
BP : BPT; 


begin 


NewC AP ); 
New(C BP ); 


AP” .Dolt; 
BP”.Dolt; 
AP:= BP; 
AP” .Doit; 


end. 


Das Programm liefert als Ergebnis die Zeilen 


Hier ist AT.Dolt 
Hier ist BT.Dolt 
Hier ist AT.Dolt 


Der Compiler hat bei der Übersetzung der Anweisung ar“.voıt einen Aufruf 
der Methode at.poıt codiert, da ar ein Zeiger auf eine Instanz von ar ist. 
Analoges gilt für die Anweisung gP*.Dott. 


Wenn ooıt als virtuelle Methode deklariert wird, ergibt sich ein unterschied- 
liches Bild. 
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type AT = object 


AVar : integer; 
constructor Make; 
procedure Dolt; virtual; 


end; {-- AT } 

type APT = "AT; 

type BT = object( AT ) 
BVar : integer; 


procedure Dolt; virtual; 
end; {-- BT } 
type BPT = "BT; 


constructor AT.Make; 
begin 
end; {-- Make } 


procedure AT.Dolt; 

begin 

writeln( ’Hier ist AT.Dolt’ ); 
end; {-- Dolt } 


procedure BT.Dolt; 

begin 

writeln( ’Hier ist BT.Dolt’ ); 
end; {-- Dolt } 


var AP : APT; 
BP : BPT; 


begin 


new( AP ); AP” .Make; 
new( BP ); BP”.Make; 


AP’ .Dolt; 
BPX.Dolt; 
AP:= BP; 
AP” .Doit; 


end. 


Die Programmausführung liefert das Ergebnis 


Hier ist AT.Dolt 
Hier ist BT.Dolt 
Hier ist BT.Dolt 


Offenbar wurde bei der ersten ar*“.Doit-Anweisung AT.DoIt, bei der zweiten 
aber Bt.poıt aufgerufen. Der Grund liegt in der vorausgegangenen Zuwei- 
sung. Sind nämlich ap und gp Zeiger auf Instanzen in einer Objekthierarchie 
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mit virtuellen Methoden, wird bei einer Zuweisung der Typ der Instanz mit 
zugewiesen. ap ist zwar als Zeiger auf ar deklariert, kann aber auch Instanzen 
der Nachfolgeobjekte aufnehmen. 


Die Regeln für Zuweisungen innerhalb von Objekthierarchien gelten auch 
hier, d.h. eine Zuweisung ap:= Bp ist möglich, die umgekehrte Zuweisung 
dagegen nicht. 


Eine Voraussetzung zur Verwendung virtueller Methoden ist die Deklaration 
eines sog. "Konstruktors". Das Schlüsselwort constructor ersetzt dabei das 
Schlüsselwort procedure, ansonsten ist die Syntax identisch zur Deklaration 
einer gewöhnlichen Methode. Ein Konstruktor wird aber anders übersetzt. 
Weiterhin muß eine Instanz eines Objekts mit virtuellen Methoden immer 
durch Aufruf des Konstruktors initialisiert werden, ansonsten ist ein Lauf- 
zeitfehler (bzw. der Systemabsturz) vorprogrammiert. 


Der Konstruktor Make enthält in diesem Beispiel keine sichtbaren Anweisun- 
gen. Es werden jedoch bestimmte interne Initialisierungen durchgeführt, die 
zur korrekten Verwendung der Instanz erforderlich sind. Der Compiler hat 
den Code für diese Initialisierungen in Make aufgenommen, da Make mit dem 
Schlüsselwort constructor definiert wurde. Beachten Sie bitte, daß der Kon- 
struktor an gr vererbt wurde. 


Konstruktoren können wie normale Methoden ausführbare Anweisungen ent- 
halten. Üblicherweise initialisiert man im Konstruktor den Datenbereich des 
Objekts. 


type AT = object 
AVar : Integer; 


constructor Make; 
procedure Dolt; virtual; 
end; {-- AT } 


APT = AT; 
type BT = object( AT ) 
BVar : Integer; 


constructor Make; 
procedure Dolt; virtual; 


end; {-- BT } 
BPT = "BT; 
constructor AT.Make; 
begin 
AVar:= 0; 


end; {-- Make } 


constructor BT.Make; 
begin 

AT.Make; 

BVar:= 0; 

end; {-- Make } 
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Beachten Sie, daß der Konstruktor von gr den Datenbereich von ar nicht sel- 
ber initialisiert, sondern dafür den Konstruktor von at verwendet. 


Man sieht, daß Konstruktoren auch wie normale Methoden aufrufbar sind. 
Die volle Mächtigkeit virtueller Methoden zeigt sich, wenn das Objekt ar in 
eine Unit verlegt wird. 


unit Vtest; 

interface 

type AT = object 
AVar : integer; 
constructor Make; 
procedure Dolt; virtual; 
end; {-- AT ) 

type APT = "AT; 

var AP : APT; 

procedure DoSomething; 

implementation 

constructor AT.Make; 

begin 

end; (-- Make } 

procedure AT.Dolt; 

begin 

writeln( ’Hier ist AT.Dolt' ); 

end; {-- Dolt } 

procedure DoSomething; 

begin 

AP“ .Dolt; 

end; (-- DoSomething } 


begin 
new AP ); AP” .Make; 


end. 


Wird die Prozedur posomething aufgerufen, wird "Hier ist AT.Dolt" ausgege- 
ben. 
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uses VTest; 


begin 
DoSomething; 
end. 


Nun fügen wir im Hauptprogramm das abgeleitete Objekt st hinzu und wei- 
sen ap einen Zeiger auf eine initialisierte Instanz dieses neuen Objekts zu. 


uses VTest; 


type BT = object( AT ) 


BVar : integer; 
procedure Dolt; virtual; 


end; {-- BT } 
type BPT = "BT; 
procedure BT.Dolt; 
begin 


writeln( 'Hier ist BT.Dolt'’ ); 
end; {-- Dolt } 


var BP : BPT; 
begin 
DoSomething; 


new( BP ); BP”.Make; 
AP:= BP; 


DoSomething; 
end. 


Bei der Ausführung dieses Programms wird "Hier ist BT.DoIt" ausgegeben! 
Ohne daß vTest neu übersetzt werden müßte, hat DoSomething eine erst im An- 
wenderprogramm definierte Routine aufgerufen. 


Wendet man dieses Beispiel auf die ursprüngliche Problemstellung der Feh- 
lerroutine in window an, erkennt man sofort den Zusammenhang. In der Unit 
Window könnte z.B. aT.DoIt die vorgegebene Fehlerroutine sein und Dosomething 
steht stellvertretend für die verschiedenen Routinen des Fenstersystems, die 
die Fehlerprozedur aufrufen. Das neue Objekt sr implementiert die neue 
Fehlerroutine BT.bolt. 
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7.3 Late Binding 


Bei näherer Betrachtung stellt sich die Frage, welche Adresse der Compiler 
bei Übersetzung von vTest beim Antreffen einer Anweisung wie AP*.Dolt für 
Dot einsetzt. Zum Zeitpunkt der Übersetzung von VTest ist nicht bekannt, 
welche Dolt-Prozedur im Endeffekt aufgerufen werden soll. Nachfolgende 
Units oder Anwendungsprogramme können beliebig viele eigene Dolt-Pro- 
zeduren implementieren. Erst zur Laufzeit des Programms kann aus dem 
Wert (bzw. genaugenommen aus dem mommentanen Typ) von ap entnommen 
werden, welche Dolt-Prozedur gemeint ist. 


Die Zuordnung von Prozeduraufruf und tatsächlich aufgerufener Prozedur 
wird hier erst zur Laufzeit des Programms hergestellt. Diesen Vorgang nennt 
man late binding. Im Gegensatz dazu bedeutet early binding, daß die Verbin- 
dung bereits zur Übersetzungszeit hergestellt wird. Technisch bedeutet early 
binding, daß beim Übersetzen einer Prozeduranweisung sofort ein Sprung 
auf die Adresse der gleichnamigen Prozedur codiert wird. Eine Folge davon 
ist, daß Prozeduren bei early binding immer erst definiert werden müssen, 
bevor sie verwendet werden können. Early binding ist das aus konventionel- 
len Programmiersprachen bekannte Verfahren. Auch bei Objekten ohne vir- 
tuelle Methoden wird early binding verwendet. 


Late Binding bedeutet aber nicht, daß die Prozedur zur Übersetzungszeit 
überhaupt noch nicht definiert sein muß. Selbst dann, wenn grundsätzlich 
eine erst später zu definierende Prozedur aufgerufen werden soll, muß trotz- 
dem aus formalen Gründen eine lokale Prozedur diesen Namens implemen- 
tiert werden. 


7.4 Formale Voraussetzungen 


Um virtuelle Methoden richtig einsetzen zu können, sind einige Vorausset- 
zungen bei der Programmierung zu beachten. 


7.4.1 Einmal virtuell - immer virtuell 


Virtuelle Methoden können nur innerhalb von Objekthierarchien verwendet 
werden. In letzten Beispiel mußte gr deshalb als Nachfolger von ar definiert 
werden. 


Ist eine Methode einmal als virtual deklariert, muß sie auch in allen Nachfol- 
gern virtuell sein. Wird die Methode vererbt, ist dies automatisch der Fall, 
wird sie redefiniert, muß sie explizit mit dem Schlüsselwort virtual versehen 
werden. Wird eine virtuelle Methode redefiniert, muß die Deklaration exakt 
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der Deklaration im Vorgänger entsprechen. Nur die Implementierung kann 
unterschiedlich sein. 


Eine Objekthierarchie mit virtuellen Methoden könnte etwa so aussehen: 
type BaseT = object 
procedure Dolt( XPos, YPos : integer ); 


end; {-- Dolt } 


type Obj1T = object( BaseT ) 


constructor Make; 
procedure Dolt( XPos, YPos : integer; Start : integer ); virtual; 


end; {-- ObJ1T } 
type Obj2T = object( Obj1T ) 
procedure Dolt( XPos, YPos : integer; Start : integer ); virtual; 
end; {-- Obj2T } 
type Obj3T = object( Obj2T ) 
procedure DoSomethingElse; 


end; {-- ObJj3T } 


Baset ist ein gewöhnliches Objekt mit einer Methode. In objır wird diese 
Methode redefiniert und gleichzeitig virtuell. Beachten Sie, daß BaseT.DoIt 
und obj1T.poıt unterschiedliche Parameterlisten haben. opj2T redefiniert Dolt, 
da obj1T.Doit bereits virtuell ist, muß auch obj2T.boıt virtuell und exakt wie 
Obj1T.Doit definiert werden. Der Konstruktor Make wird vererbt. obj3T 
schließlich erbt Make und DoIt, Dort bleibt virtuell. Die neudefinierte Methode 
DoSomethingElse Ist nicht virtuell. 


Wird eine redefinierte virtuelle Methode nicht genau wie im 
Vorgängerobjekt deklariert, bricht Turbo-Pascal die Übersetzung mit der 
Fehlermeldung error 131: Header does not match previous definition ab. Wird 
versucht, eine virtuelle Methode mit einer nicht-virtuellen Methode zu 
redefinieren, bricht Turbo-Pascal mit der Meldung Error 149: VIRTUAL expected 
ab. 


7.4.2 Konstruktoren 


Eine Instanz eines Objekts mit virtuellen Methoden muß immer durch den 
Aufruf eines Konstruktors initialisiert werden. Wird dies unterlassen, führt 
ein Aufrufversuch einer Methode dieses Objekts zum Systemabsturz. Wenn 
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die Bereichsprüfung (Compilerschalter $R, "Range checking") eingeschaltet 
ist, prüft Turbo-Pascal vor Aufruf jeder Methode, ob die Instanz initialisiert 
wurde. Falls nicht, wird der Laufzeitfehler Error 210: Objekt not initialized 
ausgelöst. 


Ein Konstruktor ist eine Methode, in deren Deklaration das Schlüsselwort 
procedure (Oder function) durch constructor ersetzt ist. Ein Konstruktor kann 
ausführbare Pascal-Anweisungen enthalten. Bevor diese beim Aufruf des 
Konstruktors ausgeführt werden, führt Turbo-Pascal interne Initialisierungen 
durch, die für die Arbeit mit virtuellen Methoden erforderlich sind. Aus die- 
sem Grunde muß ein Konstruktor auch dann aufgerufen werden, wenn er 
keine sichtbaren Anweisungen enthält. 


Da der erfolgreiche Aufruf eines Konstruktors erst die Voraussetzungen zur 
Verwendung der Instanz schafft, können Konstruktoren selber nicht virtuell 
sein. Konstruktoren haben ansonsten die gleichen Eigenschaften wie ge- 
wöhnliche Methoden. Sie können vererbt, redefiniert, oder von anderen 
Methoden aufgerufen werden. Für ein Objekt können mehrere Konstruktoren 
definiert werden, ebenso ist der mehrmalige Aufruf eines Konstruktors für 
die gleiche Instanz nicht verboten. 


7.5 Virtuelle Methoden und dynamische 
Objekte 


Virtuelle Methoden können sinnvoll nur im Zusammenhang mit dynamischer 
Speicherverwaltung bzw. mit Zeigern verwendet werden. In den beiden Bei- 
spielprogrammen aus Abschnitt 7.2 wird durch die Zuweisung ar:= BP nicht 
die Instanz selber, sondern nur ein Zeiger auf diese Instanz kopiert. Die In- 
stanz selber bleibt unverändert. Wird dagegen die Instanz selber kopiert, 
wird der Typ nicht mitübertragen, wie das folgende Beispiel zeigt. 


type AT = object 
AVar : integer; 
constructor Make; 
procedure Dolt; virtual; 


end; {-- AT ) 


type APT = "AT; 


type BT object( AT ) 


BVar : integer; 
procedure Dolt; virtual; 


end; {-- BT ) 
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type BPT "BT; 


constructor AT.Make; 
begin 
end; {-- Make ) 


procedure AT.Dolt; 

begin 

writeln( ’Hier ist AT.Dolt’ ); 
end; {-- Dolt } 


procedure BT.Dolt; 

begin 

writeln( ’Hier ist BT.Dolt’ ); 
end; {-- Dolt } 


var A: AT; 
B : BT; 


begin 


A.Make; 
B.Make; 


A.Dolt; 
B.Dolt; 
A:= B; 
A.Doit; 


end. 


Das Programm gibt als Ergebnis 


Hier ist AT.Doit 
Hier ist BT.Doit 
Hier ist AT.Doit 


aus. Das Ergebnis ist identisch z.B. aus Abschnitt 7.2 ohne virtuelle Metho- 
den. Das Versagen des Mechanismus virtueller Methoden im letzten Beispiel 
hat einen tieferen Grund. Bei der Zuweisung a:= s wird nur das Datenele- 
ment B.AVar auf A.Avar Kopiert. B.Bvar wird nicht kopiert, da at keine solche 
Variable definiert. Würde also nach der Zuweisung a:= s bei der Anweisung 
A.Dolt die Methode B.doıt aufgerufen, besteht die Gefahr, daß B.doıt auf 
nichtexistente Datenbereiche zugreift. 


7.6 Das Problem der Objektgröße 


Verschiedene Objekte einer Objekthierarchie haben im allgemeinen verschie- 
den große Datenbereiche. Die Regeln der erweiterten Zuweisungskompatibi- 


96 7 Virtuelle Methoden 


lität ermöglichen die Zuweisung von Instanzen verschiedener Objekte der 
Hierarchie an ein- und dieselbe Variable. Bei Verwendung virtueller Techni- 
ken ist dies sogar die Regel. Das Beispielprogramm aus Abschnitt 7.2 zeigt, 
daß erst durch die Zuweisung ap:= gp der Unterschied zu normalen Objekten 
deutlich wird. 


Möchte man nun den für eine Instanz zugewiesenen Speicherplatz zurückge- 
ben, kann man nicht einfach Disposec ap ) schreiben. Nach der klassischen 
Definition von pispose wird die Größe des Basistyps von ar (hier also at) zur 
Berechnung des freizugebenden Speicherplatzes verwendet. Zeigt ar gerade 
auf eine Instanz eines Nachfolgers von at, wird im allgemeinen zuwenig 
Speicher freigegeben. 


Das Problem bei der Speicherfreigabe ist nicht neu. Es tritt in der klassischen 
Programmierung ebenfalls auf, z.B. dann, wenn dynamische Variable ver- 
schiedener Typen mit typlosen Zeigern verwaltet werden sollen. Dort führt 
man eine Variable in den Datenstrukturen mit, die die Größe der Struktur 
angibt. Das Wichtige ist, daß diese Variable vom Programmierer explizit ge- 
setzt und bei der Rückgabe von Speicher verwendet werden muß. 


In der objektorientierten Programmierung haben wir in der Fallstudie Keller- 
speicher in Abschnitt 5.12 eine ähnliche Konstruktion verwendet, nur wurde 
dort nicht die tatsächliche Größe, sondern ein Aufzählungstyp zur Unter- 
scheidung der Typen verwendet. Das Setzen bzw. das Abfragen der entspre- 
chenden Variablen bei der Rückgabe des Speichers war auch hier Aufgabe 
des Programmierers. Objektorientiertes Programmieren mit virtuellen Me- 
thoden bietet hier eine einfache Möglichkeit, Objekte dynamisch zu verwal- 
ten, ohne sich um die Größe der Datenbereiche kümmern zu müssen. 


7.7 Destruktoren und Dispose 


Ein Destruktor ist eine Methode eines Objekts, die mit dem Schlüsselwort 
destructor deklariert wird. Der Destruktor im Zusammenhang mit pispose 
wird dazu verwendet, die richtige Anzahl Bytes zurückzugeben. Dazu wird 
der Destruktor als zweites Argument von Dispose aufgerufen. Das Beispiel- 
programm aus Abschnitt 7.2 kann nun um die noch fehlenden Anweisungen 
zur Speicherfreigabe erweitert werden. 
type AT = object 

AVar : integer; 

constructor Make; 

destructor Kill; 

procedure Dolt; virtual; 


end; {-- AT ) 
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type APT = MAT; 
type BT = object( AT ) 
BVar : integer; 


procedure Dolt; virtual; 
end; {-- BT ) 
type BPT = "BT; 


constructor AT.Make; 
begin 
end; {-- Make } 


destructor AT.Kill; 

begin 

end; {-- Kill } 

procedure AT.Dolt; 

begin 

writeln( ’Hier ist AT.Dolt’ ); 
end; {-- Dolt } 


procedure BT.Dolt; 

begin 

writeln( ’Hier ist BT.Dolt’ ); 
end; (-- Dolt } 


var AP : APT; 
BP : BPT; 


begin 


new( AP ); AP” .Make; 
new( BP ); BP” .Make; 


AP” .Dolt; 
BP’.Dolt; 
Dispose( AP, kill ); 


AP:= BP; 
AP“ .Doit; 


dispose( AP, kill ); 
end. 


Obwohl Dispose beidesmal mit ap aufgerufen wird, wird beim zweiten Aufruf 
die der Größe von sr entsprechende Anzahl Bytes zurückgegeben. Der De- 
struktor kitı enthält in diesem Beispiel keine ausführbaren Anweisungen. 
Der Compiler hat jedoch - gesteuert durch das Schlüsselwort destructor - 
Code zur Berechnung der Größe der aktuellen Instanz generiert. In Verbin- 
dung mit pispose kann so erreicht werden, daß immer die der Größe der ge- 
rade zugewiesenen Instanz entsprechende Menge Speicher freigegeben wird. 
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Wie jede Methode kann ein Destruktor ausführbare Anweisungen enthalten. 
Diese Anweisungen werden ausgeführt, bevor der Code zur Speicherplatzbe- 
rechnung ausgeführt wird. Ein Objekt kann mehrere verschiedene Destrukto- 
ren definieren, und Destruktoren können virtuell sein. Beachten Sie bitte, 
daß im obigen Beispiel Kilı an gr vererbt wird. Es ist zur korrekten Funktion 
des Freigabemechanismus nicht erforderlich, daß jedes Objekt seinen eigenen 
Destruktor definiert oder daß der Destruktor virtuell ist. 


Destruktoren sollen aufgerufen werden, wenn ein dynamisch erzeugtes Ob- 
jekt nicht mehr gebraucht wird. Alle Arbeiten, die zum Ende der Verwen- 
dung einer Instanz erforderlich sind, sollten in einem Destruktor zusammen- 
gefaßt werden. Im allgemeinen handelt es sich bei diesen Arbeiten um die 
Rückgabe dynamisch angeforderten Speichers. Oft benötigen Objekte einen 
variabel großen Speicherbereich zur Durchführung ihrer Aufgaben Dieser 
Speicher wird normalerweise bei der Initialisierung des Objekts vom Heap 
angefordert und bei Beendigung der Arbeit wieder zurückgegeben. 


Die Deklaration einer Methode als Destruktor hat außer im Zusammenhang 
mit Dispose keine Wirkung. Aus diesem Grunde sollten für jedes Objekt ein 
Konstruktor und ein Destruktor definiert werden. Das Objekt kann dadurch 
flexibler verwendet werden. Vielleicht entscheidet sich doch einmal ein An- 
wender, das Objekt auf dem Heap zu erzeugen? Ähnlich wie sich für den 
Namen eines Konstruktors Make oder ınit eingebürgert hat, werden Destruk- 
toren meist Kkilı oder Done genannt. 


7.3 Konstruktoren und New 


Genauso wie Dispose kann auch new als zweites Argument eine Methode über- 
geben werden. Diese Methode wird dann sofort nach Zuteilung des Speichers 
aufgerufen. Werden virtuelle Methoden verwendet, ist diese Methode meist 
der Konstruktor des Objekts. Statt 


New( BP ); BP” .Make; 


schreibt man dann einfacher 
New( BP, Make ); 
Ist Make ein Konstruktor, bietet die neue Syntax neben der Schreibvereinfa- 


chung vor allem eine Möglichkeit zur bequemen Behandlung eines Heap- 
overflow-Fehlers. 
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7.9 Abfangen von Heap-Overflow-Fehlern 


Wird versucht. mehr Speicher auf dem Heap zu reservieren als dort noch 
verfügbar ist, reagiert Turbo-Pascal standardmäßig mit dem Laufzeitfehler 
Error 203: Heap overflow error. Eine Möglichkeit, diesen Fehler und den fol- 
genden Programmabsturz zu vermeiden, ist die explizite Abfrage des noch 
zur Verfügung stehenden Speichers vor dem Aufruf von new durch die Funk- 
tion MaxAvait. Der normalerweise beschrittene Weg ist die Installation einer 
Heap-Error Routine, so daß das Fehlschlagen einer Speicheranforderung 
nicht zu einem Laufzeitfehler, sondern zu der Zuweisung von nil an den 
übergebenen Zeiger führt. Das nachfolgende Programm muß dann die Va- 
riable entsprechend auswerten. 


Wird New zusammen mit einem Konstruktor verwendet, werden eventuell 
vorhandene Anweisungen des Konstruktors nur dann ausgeführt, wenn die 
Speicherzuweisung erfolgreich war. Wenn nicht, wird der Konstruktor nicht 
aufgerufen und nil zurückgeliefert. Fordert der Konstruktor selber noch dy- 
namischen Speicher an, muß auch hier ein eventueller Speicherüberlauf abge- 
fangen werden. Ein gut programmierter Konstruktor macht die bis dahin er- 
folgreich durchgeführten Initialisierungen rückgängig. Auch in einem sol- 
chen Falle wäre es wünschenswert, daß der bereits zugewiesene Speicher- 
platz für die Instanz wieder freigegeben und der zugeordnete Zeiger auf nil 
gesetzt wird. Turbo-Pascal stellt für diesen Zweck die neue Prozedur rait be- 
reit. 


Der Aufruf von rail macht das erfolgreiche Ergebnis von new rückgängig. Im 
folgenden Programm benötigt das Objekt ar 20k-Byte internen Speicher, die 
auf zwei Variablen verteilt werden sollen. Sowohl der Speicherplatz für die 
Instanz selber als auch der für die lokalen Daten werden vom Heap angefor- 
dert. 


type TenKT = array[ 1..10000 ] of char; 
type AT = object 
Local1P, Local2P : *TenKT; 


constructor Make; 
destructor Kill; 
procedure Dolt; virtual; 
end; {-- AT ) 


type APT = "MT; 
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constructor AT.Make; 
begin 


new( LocaliP ); 
if LocaliP = nil then 
fail; 


new( Local2P ); 

if Local2P = nil then 
begin 
Dispose( Local1P ); 
fail; 
end; 


end; {-- Make } 


destructor AT.Kill; 
begin 

Dispose( LocaliP ); 
Dispose( Local2P ); 
end; {-- Kill } 


procedure AT.Dolt; 

begin 

writeln( ’Hier ist AT.Dolt’ ); 
end; {-- Dolt ) 


var AP : APT; 

{$F+) 

function Heapfunc( Size : word ) : integer; 
begin 


Heapfunc:= 1; 
end; {-- Heapfunc } 
{$F-} 


begin 


{-- Installation Heap Error Routine --} 
HeapError:= aHeapFunc; 


new( AP, Make ); 
if AP = nil then 


begin 

writeln( ’nicht genuegend Speicher !’ ); 
haltl 1); 

end; 


{-- Eigentliches Programm --) 


Dispose( AP, Kill ); 
end. 


In diesem Programm kann an drei Stellen ein Speicherüberlauf auftreten. Zu- 
erst versucht New, ausreichend Speicher für eine Instanz von AT zu 
reservieren. Gelingt das nicht, liefert new sofort nil zurück, ansonsten wird 
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Make ausgeführt. Wenn in Make keine 10k-Bytes reserviert werden können, 
sorgt der Aufruf von rail dafür, daß bereits zugewiesener Speicher für die 
Instanz von ar wieder zurückgegeben wird und ap wiederum den Wert nil 
erhält. Die zweite Speicheranforderung wurde in das Programm 
aufgenommen, um auf einen häufig gemachten Fehler hinzuweisen. Es darf 
nämlich nicht vergessen werden, vor dem Aufruf von rail die bereits 
erfolgreich zugewiesenen ersten 10k-Bytes auch wieder freizugeben! 


Im obigen Beispiel braucht nach der Erzeugung der Instanz nur der zurück- 
gelieferte Zeiger auf den Wert nil geprüft werden, um alle Fehlersituationen 
abfangen zu können. Wird at zur Ableitung eines weiteren Objekts verwen- 
det und wird dort der Konstruktor von at aufgerufen, kann keine Variable 
abgefragt werden. Ein Konstruktor kann deshalb auch als Funktion vom Typ 
boolean verwendet werden. Liefert der Konstruktor FALSE, wurde innerhalb 
des Konstruktors rail aufgerufen. 


Im folgenden Programmsegment ist sr von ar abgeleitet. gr benötigt zusätz- 
lich 10k-Bytes Speicher. 


type BT = object( AT ) 
LocalP : *TenKT; 


constructor Make; 
destructor Kill; 
procedure Dolt; virtual; 
end; {-- AT } 

BPT = BT; 


constructor BT.Make; 
begin 


if not AT.Make then 
Fail; 


New( LocalP ); 
if LocalP = nil then 
Fail; 


end; (-- Make ) 
destructor BT.Kill; 


AT.KilL; 

Dispose( LocalP ); 

end; {-- Kill } 

procedure BT.Dolt; 

begin 

Writeln( ’Hier ist BT.Dolt’ ); 
end; {-- Dolt } 


Da gt von ar abgeleitet ist, sollte der Konstruktor von sr zunächst den Kon- 
struktor von at aufrufen, bevor eigene Initialisierungen durchgeführt werden. 
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AT.Make wird hier als Funktion verwendet, obwohl die Methode als Prozedur 
deklariert wurde. Der zurückgelieferte Funktionswert ist TRUE, wenn 
AT.Make Tichtig ausgeführt werden konnte. Der Aufruf von rait innerhalb von 
AT.Make bewirkt die Rückgabe von FALSE. 


7.10 Zweite Fallstudie Kellerspeicher 


In Abschnitt 5.12 haben wir Routinen zur Implementierung eines Kellerspei- 
chers vorgestellt. Wir haben dabei von der erweiterten Zuweisungskompati- 
bilität innerhalb von Objekthierarchien Gebrauch gemacht, um verschiedene 
Objekte mit dem Kellerspeicher verwalten zu können. Die Handhabung des 
Kellerspeichers war jedoch etwas umständlich, vor allem weil der Typ der 
Objekte explizit verwaltet werden mußte, um eine korrekte Beförderung 
durchführen zu können. 


7.10.1 Aufgabenstellung 


In dieser Fallstudie soll der Kellerspeicher unter Verwendung virtueller Me- 
thoden so erweitert werden, daß die Notwendigkeit zur expliziten Beförde- 
rung von Instanzen durch den Programmierer und damit auch die Notwen- 
digkeit zum Mitführen des Objekttyps entfällt. 


7.10.2 Realisierung 


Die eigentlichen Kellerspeicherroutinen werden kaum geändert, die Neue- 
rung liegt in der Gestaltung der abzulegenden Objekte mit virtuellen Metho- 
den. Auch in dieser Implementierung des Kellerspeichers weiß der Entwick- 
ler nicht, für welche Datentypen der Kellerspeicher verwendet werden wird. 
Er muß deshalb auch hier ein Urelement deklarieren, von dem der Anwender 
dann die eigentlichen Datenelemente ableiten kann. Die Ausstattung des Ur- 
elements mit einer Statusvariablen ist aber nicht mehr erforderlich, dafür 
werden ein Konstruktor und ein Destruktor definiert. 


7.10.3 Der Interfaceteil 


Der Interfaceteil hat sich gegenüber dem ursprünglichen Kellerspeicher we- 
nig geändert. Im Wesentlichen sind Konstruktoren und Destruktoren sowie 
die Methode stackt.Clear hinzugekommen. 
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unit VStackU; 


{ 
StackT definiert einen Stack mit 10 Elementen. 
Push legt ein Element ab, liefert true wenn noch Platz 
fuer ein weiteres Element ist. 
Pop liefert eine Element, nil wenn Stack leer ist. 
> 
interface 
{-- Urtyp eines Stackelements ------------------- HH 00000 > 
type StackElmT = object 
constructor Make; 
destructor Kill; virtual; 
end; {-- StackElmT ) 
StackElmPT = *StackElmT; 
{-- Der Stack selber -------------------------- 7-7 7777 777707700000 > 
const MaxEntriesC = 10; 
type StackT = object 
Buffer : array[ 1..MaxEntriesC ] of StackElmPT; 
Index : integer; 
constructor Make; 
destructor Kill; 
function Push( EP : StackElmPT ) : boolean; 
function Pop : StackElmPT; 
procedure Clear; 
end; (-- StackT } 
implementation 


{$1 VS150 3 €-- Make, Kill fuer StackElmT ) 
{$1 VS110 3 €-- Make, Kill } 

{$I S120 3 €-- Push, Pop } 

{$I vS130 3 €-- Clear } 


end. 


7.10.4 Die Implementierung 


Im neuen Objekt stackt sind die Methoden Make und kitı nun als Konstruktor 
und Destruktor deklariert. Die Implementierung ist in der Datei VS110 un- 
tergebracht 
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{--- Implementierung StackT Make, Kill ----) 


constructor StackT.Make; 
begin 

Index:= 1; 

end; {-- Make ) 


destructor StackT.Kill; 
begin 
end; {-- Kill } 


Die neue Methode cıiear soll alle Einträge des Kellerspeichers löschen und 
gleichzeitig den für die Instanzen zugewiesenen Speicherplatz zurückgeben. 


procedure StackT.Clear; 
var | : Integer; 


begin 

for 1:= 1 to Pred( Index ) do 
Dispose( Bufferf I ], Kill ); 

end; {-- Clear ) 


Hier ist ersichtlich, daß man sich beim Entwurf von clear nicht um die 
tatsächliche Größe der abgelegten Instanzen kümmern muß. Dispose in Ver- 
bindung mit dem Destruktor kitı stellt sicher, daß die Größe der aktuellen 
Instanz verwendet wird. Beachten Sie bitte, daß die Speicherberechnung auch 
dann korrekt durchgeführt würde, wenn ureimt.Kitt nicht virtuell wäre. Die 
Deklaration von kitı als Destruktor bewirkt die richtige Berechnung, nicht 
die Deklaration als virtuelle Methode. Warum kitı trotzdem virtuell sein 
sollte, werden wir später sehen. Das folgende Listing zeigt die restlichen 
Includedateien VS150 und S120: 


constructor StackElmT .Make; 
begin 
end; 


destructor StackElmT.Kill; 
begin 
end; 
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{--- Implementierung StackT Push, Pop --} 


function StackT.Push( EP : StackElmPT ) : boolean; 
begin 
if Index = MaxEntriesC then {-- Speicher voll. EP nicht eintragen } 
begin 
Push:= false; 
exit; 
end; 


Buffer[ Index ] := EP; 
inc Index ); 
Push:= true; 


end; (-- Push } 


function StackT.Pop : StackElmPT; 
begin 
if Index = 1 then {-- Speicher leer. nil zurueckliefern } 
begin 
Pop:= nil; 
exit; 
end; 


dec( Index ); 
Pop:= Buffer[ Index ]; 


end; {-- Pop ) 


7.10.5 Eine kleine Anwendung 


Betrachten wir nun die fertige Unit aus der Sicht eines Anwendungspro- 
grammierers. Bei der Entwicklung eines Anwenderprogramms erscheint es 
uns sinnvoll, den Kellerspeicher zur Verwaltung von Gleitkommazahlen und 
komplexen Gleitkommazahlen zu verwenden. Wir definieren zu diesem 
Zweck die beiden Objekte RealT und ComplexT. 


type RealT = object( StackElmT ) 
R : real; 
end; {-- RealT ) 
RealPT = *RealT; 
type ComplexT = object( StackElmT ) 
XReal, XlImg : real; 


end; {-- ComplexT } 
ComplexPT = *ComplexT; 
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Ein Testprogramm, das den neuen Kellerspeicher mit Realt und ComplexT 
nutzt, könnte etwa so aussehen: 


uses VStackU; 


type RealT = object( StackElmT ) 
R : real; 
end; {-- RealT } 
RealPT = "RealT; 
type ComplexT = object( StackElmT ) 
XReal, XlImg : real; 
end; {-- ComplexT ) 
ComplexPT = “ComplexT; 
var Stack : StackT; 
var RealP : RealPT; 
ComplexP : ComplexPT; 
var I : integer; 
begin 


Writeln( "vor Programmausfuehrung : ', MemAvail ); 
Stack.Make; 


for I:= 1 to 8 do 

if OddC I ) then 
begin 
New( RealP, Make ); 
if not Stack.Push( RealP ) then Halt; 
end 

else 
begin 
New( ComplexP, Make ); 
if not Stack.Push( ComplexP ) then Halt; 
end; 


Stack.Clear; 

Stack.Kill; 

writeln( "nach Programmausfuehrung : ’, MemAvail ); 
end. 


Die beiden Ausgabeanweisungen liefern den gleichen Wert und zeigen damit, 
daß die Speicherverwaltung richtig funktioniert. 


Als nächster Schritt sollen Reatt und Comptext so erweitert werden, daß sie zur 
Datenspeicherung verwendet werden können. Zusätzlich soll der Inhalt des 
Kellerspeichers ausgedruckt werden können. Die zum Ausdruck erforderli- 
chen Anweisungen werden als eigene Prozedur mit dem Namen printall ZU- 
sammengefaßt. Es wäre sinnvoll, diese Prozedur als Methode zu stackt zu 
formulieren, aber als Anwender der Unit gehen wir davon aus, daß der 
Quellcode nicht zur Verfügung steht. Eine solche Situation tritt bei der Pro- 
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grammentwicklung recht häufig auf, unabhängig davon ob man konventionell 
oder objektorientiert programmiert. 


Mit objektorientierter Programmierung ist die Lösung einfach. Wir leiten im 
Anwenderprogramm ein eigenes Objekt ab, das die neue Methode aufnehmen 
kann. 


uses VStackU; 
(-- Die Deklarationen fuer den neuen Stack mit Print-Prozedur --) 


type MyStackElmT = object( StackElmT ) 
procedure Print; virtual; 
end; {-- MyStackElmT } 
MyStackElmPT = *MyStackElnT; 


type MyStackT = object( StackT ) 
procedure PrintAll; virtual; 
end; {-- MyStackT } 


{-- Die Deklarationen fuer die Nutzdaten --} 


type RealT = object( MyStackElnT ) 
R : real; 
constructor Make( NewR : real ); 
procedure Print; virtual; 
end; {-- RealT } 


RealPT = *RealT; 
type ComplexT = object( MyStackElmT ) 
XReal, Xlmg : real; 


constructor Make( NewXReal, NewXImg : real ); 
procedure Print; virtual; 
end; {-- ComplexT } 

ComplexPT = *ComplexT; 


{$I MS110 3 (-- Print fuer MyStackElmT } 
{$1 MS111 3 {-- PrintAll fuer MySTackT ) 
{$I MS120 } {-- Methoden fuer RealT und ComplexT )} 


var Stack : MyStackT; 
var RealP : RealPT; 

ComplexP : ComplexPT; 
var | : integer; 
begin 


Writeln( ’vor Programmausfuehrung : ’, MemAvail ); 
Stack.Make; 
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for I:= 1 to 8 do 
if Odd( I ) then 
begin 
New( RealP, Make( I ) ); 
if not Stack.Push( RealP ) then Halt; 


begin 

New( ComplexP, Make( I, -I ) ); 

if not Stack.Push( ComplexP ) then Halt; 
end; 


Stack.PrintAll; 

Stack.Clear; 

Stack.Kill; 

Writeln( ’nach Programmausfuehrung : '!, MemAvail ); 
end. 


Neben dem neuen Kellerspeicher mystackt ist in diesem Programm auch ein 
neues Datenurelement (MmyStackEimt) definiert worden. Entsprechend werden 
RealT und Complext nicht mehr von StackElmt, sondern von MyStackElmt abgelei- 
tet. Wir werden mystackElmt später zur Deklaration von Zeigern verwenden. 
Von MyStackElmt selber werden keine Instanzen gebildet. MyStackElmt.Print 
wird deshalb nicht aufgerufen. Zur Sicherheit kann die Methode aber trotz- 
dem einen erklärenden Text ausgeben. 


procedure MyStackElmT.Print; 

begin 

Writeln( "Keine Printfunktion implementiert !’ ); 
end; {-- Print } 


Die Nutzdatenobjekte Reatt und Comptext haben nun explizite Konstruktoren 
erhalten, die gleichzeitig die Variablen des Datenbereiches initialisieren. Be- 
achten Sie, wie die beiden unterschiedlichen Make-Methoden im Hauptpro- 
gramm zusammen Mit new verwendet werden. Die print-Methoden der Nutz- 
datenobjekte sollen den jeweiligen Datenbereich auf dem Bildschirm ausge- 
ben. 


Die Datei MS120 enthält die Implementierung der Methoden von Reatt und 
ComplexT: 


{---- Methoden fuer ComplexT ---) 


constructor RealT.Make( NewR : real ); 
begin 

R:= NeuR; 

end; {-- Make } 


procedure RealT.Print; 
begin 

Writelnt ’RealZahl : ', R ); 
end; {-- Print } 
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{---- Methoden fuer ComplexT ---) 


constructor ComplexT.Make( NewXReal, NewXImg : real ); 
begin 

XReal:= NewXReal; 

XiImg := NewXImg; 

end; {-- Make } 


procedure ComplexT.Print; 

begin 

Writeln( ’Komplexe Zahl : (’, Xreal, ' ', XImg, ' )'’); 
end; {-- Print } 


Die neue Methode myStackT.Printalt ist in der Datei MS111 untergebracht: 
procedure MyStackT.PrintAll; 

var | : integer; 

begin 


for I:= 1 to Pred( Index ) do 
MyStackElmPT( Buffer[ I ] )“.Print; 


end; {-- PrintAll } 


Pop liefert als Ergebnis einen Zeiger vom Typ StackElmt. Da StackElmt keine 
print-Methode definiert, könnte der Zeiger nicht zum Aufruf von RealT.Print 
oder ComplexT.Print verwendet werden, selbst dann nicht, wenn der Zeiger auf 
eine Instanz dieser Objekte zeigt. Die Deklaration des neuen Daten-Urele- 
ments MyStackElmt löst das Problem, wenn auch eine explizite Typumwand- 
lung unvermeidlich ist. 


Zum Schluß dieses Abschnitts soll ein kleiner Trick verraten werden, der 
zwar von Puristen der objektorientierten Programmierung nicht gern gese- 
hen, aber von Turbo-Pascal Programmierern häufig verwendet wird, um die 
Deklaration von MyStackElmt zu vermeiden. Aufgrund der Implementierung 
des Mechanismus virtueller Methoden in Turbo-Pascal kann nämlich zur ex- 
pliziten Typumwandlung in myStackT.Printall auch direkt Reatpt oder StringPT 
verwendet werden. MyStackT.Printalt erhält dann diese Form (Datei MS111a): 


procedure MyStackT.PrintAll; 
var I : integer; 
begin 


for I:= 1 to Pred( Index ) do 
RealPT( Buffer[ I ] )*.Print; 


end; (-- Print } 
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Im Hauptprogramm werden Realt und Complext nun wieder von StackElmt ab- 
geleitet 


uses VStackU; 
{-- Die Deklarationen fuer den neuen Stack mit Print-Prozedur --} 


type MyStackT = object( StackT ) 
procedure PrintAll; virtual; 
end; {-- MyStackT } 


{-- Die Deklarationen fuer die Nutzdaten --} 


type RealT = object( StackElmT ) 
R : real; 
constructor Make( NewR : real ); 
procedure Print; virtual; 
end; (-- RealT )} 
RealPT = *RealT; 


type ComplexT object( StackElmT ) 
XReal, XImg : real; 
constructor Make( NewXReal, NewXImg : real ); 
procedure Print; virtual; 
end; (-- ComplexT ) 
ComplexPT = *ComplexT; 


{$1 MS111a} (-- PrintAll fuer MySTackT } 
{$1 MS120 } C-- Methoden fuer RealT und ComplexT } 


var Stack : MyStackT; 
var RealP : RealPT; 
ComplexP : ComplexPT; 
var I : integer; 
begin 
Writelnt "vor Programmausfuehrung : ', MemAvail ); 
Stack .Make; 


for I:= 1 to 8 do 

if Odd( I ) then 
begin 
New( RealP, Make( I ) ); 
if not Stack.Push( RealP ) then Halt; 
end 

else 
begin 
New( ComplexP, Make( I, -I ) ); 
if not Stack.Push( ComplexP ) then Halt; 
end; 


Stack.PrintAll; 

Stack.Clear; 

Stack.Kill; 

writeln( 'nach Programmausfuehrung : ’, MemAvail ); 
end. 
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Dieser Trick setzt voraus, daß Reatpr im Objekt mystackt bekannt ist. In unse- 
rem Beispiel ist das deshalb der Fall, weil mystackt nicht als Unit, sondern di- 
rekt im Anwendungsprogramm formuliert wurde. Möchte man die neue 
Funktionalität von mystackt ebenfalls datenunabhängig halten, muß der Weg 
über die Deklaration des polymorphischen Objekts MystackElmt gegangen 
werden. 


7.10.6 Neue Syntax für New 


Im letzten Programm wurden die Variablen Reatp und complexp dazu verwen- 
det, neu erzeugte Instanzen von RealT und Comptext aufzunehmen. Innerhalb 
von Printall z.B. wird zur Zuweisung der verschiedenen Instanzen nur eine 
Variable benötigt. Wegen der erweiterten Zuweisungskompatibilität inner- 
halb von Objekthierarchien ist dies problemlos möglich. 


Turbo-Pascal bietet die Möglichkeit, auch bei der Erzeugung von Instanzen 
allgemeine Variablen zu verwenden. Zeigervariable werden dann nur noch 
vom Typ des Urvaterobjekts in der Hierarchie deklariert. Diesen Zeigern 
können Instanzen beliebiger Objekte der Hierarchie zugewiesen werden. Im 
obigen Beispiel ist das Urvaterobjekt mystack£lmt. Zur Arbeit mit Instanzen 
von RealT und Complext (und später evtl. weiteren Objekten der Hierarchie) 
reichen Zeigervariablen vom Typ "MyStackEimpt aus. Bei der Zuweisung von 
Speicher mit new ist nun aber ein weiterer Parameter erforderlich, der angibt, 
von welchem Objekt eine Instanz erzeugt werden soll. Statt 


New( RealP, Make( I ) ); 


schreibt man dann 


RealP:= New( RealPT, Make( I ) ); 


Newerhält als erstes Argument nur noch den Typ der gewünschten Instanz und 
liefert einen Zeiger auf den angeforderten Datenbereich (bzw. nil) zurück. 
Die aufnehmende Variable muß nicht mehr vom Typ Realpt sein, sondern 
kann - wegen der erweiterten Zuweisungskompatibilität - auch eine Zeiger- 
variable eines Vorgängers von RealT sein. 


Das folgende Listing zeigt eine Modifikation des letzten Programms , in der 
Zeigervariablen vom Typ RealPpt und complexpt nicht mehr erforderlich sind. 
Alle Zeigeroperationen werden mit Variablen vom Typ MyStackElmpt ausge- 
führt. 
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uses VStackU; 
(-- Die Deklarationen fuer den neuen Stack mit Print-Prozedur --} 


type MyStackElmT = object( StackElmT ) 
procedure Print; virtual; 
end; {-- MyStackElmfT } 
MyStackElmPT = *MyStackElmT; 


type MyStackT = object( StackT ) 
procedure PrintAll; virtual; 
end; {-- MyStackT } 


{-- Die Deklarationen fuer die Nutzdaten --} 


type RealT = object( MyStackElmT ) 
R : real; 
constructor Make( NewR : real ); 
procedure Print; virtual; 
end; {-- RealT } 


RealPT = "RealT; 
type ComplexT = object( MyStackElmT ) 
XReal, Xlmg : real; 


constructor Make( NewXReal, NewXImg : real ); 
procedure Print; virtual; 
end; {-- ComplexT } 

ComplexPT = *ComplexT; 


{$1 MS110 } (-- Print fuer MyStackElmT } 
{$1 MS111 3 (-- PrintAll fuer MySTackT } 
{$1 MS120 } {-- Methoden fuer RealT und ComplexT } 


var Stack : MyStackT; 

var WorkP : MyStackElmPT; 

var I : integer; 

begin 

Writeln(C 'vor Programmausfuehrung : ', MemAvail ); 
Stack ..Make; 


for I:= 1 to 8 do 
begin 


if OddC I ) then 
WorkP:= New( RealPT, Make( I ) ) 
else 
WorkP:= New( ComplexPT, Make( I, -I ) ); 


if not Stack.Push( WorkP ) then Halt; 
end; 


Stack.PrintAll; 

Stack.Clear; 

Stack.Kill; 

writeln( ’nach Programmausfuehrung : ’, MemAvail ); 
end. 
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7.10.7 Erweiterung um ein größeres Objekt 


Wir wollen das Beispiel um ein Objekt, das selber zusätzlichen dynamischen 
Speicher benötigt, erweitern. Wir nehmen an, daß das Objekt konstant 10k- 
Bytes Speicher benötigt. Normalerweise könnte man bei einem konstanten 
Speicherbedarf auf eine dynamische Speicherverwaltung innerhalb des Ob- 
jekts verzichten und den benötigten Speicher fest im Datenbereich des Ob- 
jekts deklarieren. Die dynamische Anforderung und Freigabe ist nur dann 
notwendig, wenn die Größe des erforderlichen Speicherbereiches erst zur 
Laufzeit bestimmt werden kann oder von Instanz zu Instanz unterschiedlich 
ist. Um die Vorgehensweise zu demonstrieren, beschränken wir uns im fol- 
genden Beispiel auf eine feste Größe von 10K-Bytes. 


type BigChunkT = array[ 1..10000 ]} of char; 
BigChunkPT = *BigChunkT; 


type BigObjT object( MyStackElmT ) 
BigChunkP : BigChunkPT; 
constructor Make; 
destructor Kill; virtual; 
end; (-- BigObjT }) 
BigObjPT = *BigObjT; 


Wir nehmen an, daß eine Print-Funktion für dieses Objekt nicht sinnvoll ist 
und definieren deshalb keine eigene print-Methode. Die Anforderung und 
Rückgabe des Speichers wird im Konstruktor und Destruktor durchgeführt 
(Datei MS121): 


constructor BigObjT.Make; 
begin 

new( BigChunkP ); 

if BigChunkP = nil then fail; 
end; {-- Make } 


destructor BigObjT.Kill; 
begin 

dispose( BigChunkP ); 
end; {-- Kill } 


Die Erweiterung des Beispiels zur Nutzung des Kellerspeichers zeigt das 
folgendes Listing. 
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uses VStackU; 
(-- Die Deklarationen fuer den neuen Stack mit Print-Prozedur --} 


type MyStackElmT = object( StackElmT ) 
procedure Print; virtual; 
end; {-- MyStackElmT } 
MyStackElmPT = “MyStackElmT; 


type MyStackT = object( StackT ) 
procedure PrintAll; virtual; 
end; {-- MyStackT } 


{-- Die Deklarationen fuer die Nutzdaten --) 


type RealT = object( MyStackElmT ) 
R : real; 
constructor Make( NewR : real ); 
procedure Print; virtual; 
end; {-- RealT ) 


RealPT = *RealT; 
type ComplexT = object( MyStackElmT ) 
XReal, XlImg : real; 


constructor Make( NewXReal, NewXImg : real ); 

procedure Print; virtual; 

end; {-- ComplexT )} 
ComplexPT 


*ComplexT; 


arrayl 1..10000 ] of char; 
*BigChunkT; 


type BigChunkT 
BigChunkPT 


type BigObjT object( MyStackElmT ) 
BigChunkP : BigChunkPT; 
constructor Make; 
destructor Kill; virtual; 
end; (-- BigObJT } 
BigObjPT = *BigObjT; 


{$1 MS110 ) (-- Print fuer MyStackElmT )} 

{$I MS111 3 (-- PrintAll fuer MySTackT ) 

{$1 MS120 ) {-- Methoden fuer RealT und ComplexT ) 
{$1 MS121 ) {-- Methoden fuer BigObjT } 

var Stack : MyStackT; 

var WorkP : MyStackElmPT; 


var I : integer; 
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begin 
Writeln( 'vor Programmausfuehrung : ’, MemAvail ); 
Stack.Make; 


for I:= 1 to 8 do 
begin 


case Random( 3 ) of 


0 : WorkP:= New( RealPT, Make( I ) ); 

1 : WorkP:= New( ComplexPT, Make( I, -1I ) ); 
2 : WorkP:= New( BigObjPT, Make ); 

end; 


if WorkP = nil then 
Writeln(C 'nicht genug Speicher !’ ) 
else 
if not Stack.Push( WorkP ) then 
Writeln( ’Stackueberlauf’ ); 


end; 


Stack.PrintAll; 

Stack.Clear; 

Stack.Kill; 

writeln( ’nach Programmausfuehrung : ’, MemAvail ); 
end. 


Am Beispiel von Bigobjr wird klar, warum bei der Entwicklung der Unit 
vStacku der Destruktor des Urelements bereits virtuell sein sollte. Enthält der 
Kellerspeicher Instanzen vom Typ Bigobjt und wird clear aufgerufen, würde 
sonst nicht BigobjT.Kilt sondern MyStackElmt.Kilt aufgerufen. Die Folge wäre, 
daß die 10k-Bytes lokaler Speicher dieser Instanz nicht freigegeben würden. 


DoSomething ruft für alle Instanzen des Kellerspeichers die Methode Print auf. 
Das neue Objekt Bigobjt definiert jedoch keine eigene Print-Methode. Daher 
wird die gleichnamige Methode des Vorgängers aufgerufen, die die Meldung 
Keine Printfunktion implementiert ! ausgibt. 


Die Definition einer Print-Methode mit einer Fehlermeldung bereits in 
MyStackElmt zeigt ein wichtiges Prinzip beim Entwurf von Objekthierarchien. 
Bei der Entwicklung einer Hierarchie sollte man grundsätzlich ein Urelement 
definieren, von dem die Arbeitszeiger im Programm definiert werden kön- 
nen. Das Urelement soll bereits alle virtuellen Methoden, die die Nachfolge- 
objekte benötigen, ebenfalls definieren. Die Implementierung sollte z.B. eine 
Fehlermeldung produzieren oder eine Fehlerroutine aufrufen. Wenn für ein 
Objekt tatsächlich keine sinnvolle Print-Methode definiert werden kann, 
sollte zumindest eine Dummy-Prozedur implementiert werden, um den Auf- 
ruf der Fehlerroutine im Urobjekt zu vermeiden. Im Falle von Bigobjt wäre 
es also besser gewesen zu schreiben: 
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array[ 1..10000 ] of char; 
*BigChunkT; 


type BigChunkT 
BigChunkPT 


type BigObjT object( MyStackElmT ) 
BigChunkP : BigChunkPT; 
constructor Make; 
destructor Kill; virtual; 
procedure Print; virtual; 
end; (-- BigObjT } 
BigObjPT = *BigObjT; 


procedure BigObJT.Print; begin end; 


Betrachten wir noch einmal das Programm auf Seite 109. Dort konnte auf die 
Deklaration von MyStackElmt verzichtet werden, da für die notwendige Typ- 
umwandlung in printatl direkt der Typ Reatpt verwendet wurde. Nach dem 
Hinzufügen des Objekts Bigobjr ist ersichtlich, warum dieser Trick - wenn 
auch häufig verwendet - nicht zu empfehlen ist. Das folgende Listing zeigt 
das um Bigobjr erweiterte Programm von Seite 109 


uses VStackU; 
{-- Die Deklarationen fuer den neuen Stack mit Print-Prozedur --} 


type MyStackT = object( StackT ) 
procedure PrintAll; virtual; 
end; {-- MyStackT } 


{-- Die Deklarationen fuer die Nutzdaten --} 


type RealT = object( MyStackElmT ) 
R : real; 
constructor Make( NewR : real ); 
procedure Print; virtual; 
end; {-- RealT ) 
RealPT = *RealT; 


type ComplexT object( MyStackElnmT ) 
XReal, XImg : real; 
constructor Make( NewXReal, NewXImg : real ); 
procedure Print; virtual; 
end; {-- ComplexT } 
ComplexPT 


*ComplexT; 


array[ 1..10000 ] of char; 
*BigChunkT; 


type BigChunkT 
BigChunkPT 


type BigObjT object( StackElmT ) 
BigChunkPp : BigChunkPT; 
constructor Make; 
destructor Kill; virtual; 
end; {-- BigObjT } 
BigObjPT = *BigObjT; 


{$1I MS111a) {-- PrintAll fuer MySTackT } 
{$I MS120 3 {-- Methoden fuer RealT und ComplexT } 
{$I MS121 } {-- Methoden fuer BigObjT } 
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var Stack : MyStackT; 

var WorkP : MyStackElmPT; 
var I : integer; 
begin 


Writeln( ’vor Programmausfuehrung : ', MemAvail ); 
Stack.Make; 


for I:= 1 to 8 do 
begin 


case Random( 3 ) of 


0 : WorkP:= New( RealPT, Make( I ) ); 

1 : WorkP:= New( ComplexPT, Make( I, -I ) ); 
2 : WorkP:= New( BigObjPT, Make ); 

end; 


if WorkP = nil then 
Writeln( ’nicht genug Speicher !’ ) 
else 
if not Stack.Push( WorkP ) then 
Writeln( ’Stackueberlauf’ ); 


end; 


Stack.PrintAll; 

Stack.Clear; 

Stack.Kill; 

Writeln( ’nach Programmausfuehrung : ', MemAvail ); 
end. 


BigobjT ist hier als direkter Nachfolger von stackElmt definiert. Der Aufruf 


RealPT( Buffer[ I ] )*.Print; 


in Printall bewirkt bei einer Instanz ohne Print-Methode den Sprung zu einer 
nicht definierten Adresse mit der Folge, daß der Rechner meist neu gebootet 
werden muß. In der internen Tabelle für virtuelle Prozeduren ist im Falle von 
Bigobjt kein Eintrag für print vorhanden. An der entsprechenden Stelle 
stehen schon die Daten der nächsten Variablen. Durch die explizite 
Typumwandlung werden die sonst strengen Typprüfungen des Compilers 
vom Programmierer außer Kraft gesetzt. Bei solchen Konstruktionen ist 
daher größte Vorsicht geboten. 


7.10.8 Resume 


Als Ergebnis können wir festhalten, daß der Kellerspeicher mit virtuellen 
Methoden ohne Kenntnis der in einem Anwenderprogramm auftretenden 
Datenstrukturen realisiert werden kann. Der damit normalerweise verbun- 
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dene Aufwand zur expliziten Typumwandlung kann in den meisten Fällen 
vermieden werden. Ebenso kann das Problem der Bestimmung der aktuellen 
Größe einer Instanz bei Verwendung virtueller Methoden auf den Compiler 
abgewälzt werden. Diesen Vorteilen steht der Nachteil gegenüber, daß Ob- 
jekte mit virtuellen Methoden grundsätzlich durch Aufruf eines Konstruktors 
initialisiert werden müssen. Dieser Nachteil wird allerdings dadurch relati- 
viert, daß die meisten Objekte Datenbereiche definieren, die sowieso initiali- 
siert werden müssen. Es ist guter Programmiierstil, diese Initialisierungen im 
Konstruktor zusammenzufassen. Durch die Deklaration als Konstruktor wird 
die für Turbo-Pascal intern wichtige Initialisierung quasi nebenbei mit erle- 
digt. Analoges gilt auch für den Destruktor. 


7.11 "Virtuelle Methoden" in traditionellem 
Pascal 


Erfahrenen Turbo-Pascal Programmierer verwenden gerne Prozedurvari- 
ablen, wenn eine Prozedur aufgerufen werden soll, die erst zur Laufzeit be- 
stimmt werden kann. Das folgende Programmsegment deklariert einen Pro- 
zedurtyp und eine Prozedurvariable. 


type ProcT = procedure( S : string ); 


var Proc1 : ProcT; 


proci kann z.B. dazu verwendet werden, um für alle Elemente des Kellerspei- 
chers eine Prozedur aufzurufen, die erst zur Laufzeit bestimmt werden kann. 
Wir haben vorausgesetzt, daß der Kellerspeicher Datenelemente vom Typ 
pointer verwalten soll. Eine Arbeitsprozedur, die dies leistet, könnte etwa so 
aussehen: 


procedure DoSomething( var Stack : StackKT; Proc : ProcT ); 
var I : integer; 


begin 

for I:= 1 to Stack.Index do 
Proc( Stack.Buffer[ I ] ); 

end; {-- DoSomething } 


Die Prozedurdeklaration zusammen mit Dosomething und der Implementierung 
der Kellerspeicherroutinen für allgemeine Zeiger kann in einer Unit unterge- 
bracht werden. Im folgenden Listing sind die Kellerspeicherroutinen push und 
Pop nicht gezeigt, da sie in diesem Zusammenhang unwichtig sind. 
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unit StackU2; 


interface 

type ProcT = procedure( P : pointer ); 

const MaxEntriesC = 10; 

type StackT = record 
Buffer : array[ 1..MaxEntriesC ] of pointer; 
Index : Integer; 
end; 


procedure DoSomething( var Stack : StackT; Proc : ProcT ); 
implementation 


procedure DoSomething( var Stack : StackT; Proc : ProcT ); 
var I : integer; 
begin 
for I:= 1 to Stack.Index do 
Proc( Stack.Buffer[ I ] ); 
end; {-- DoSomething } 


end. 


Mit dieser Konstruktion hat man erreicht, daß die Prozedur posomething der 
Unit andere Prozeduren aufrufen kann, die zur Übersetzungszeit der Unit 
noch nicht bekannt sein müssen. Dieses Ziel kann auch durch objektorien- 
tierte Programmierung mit virtuellen Methoden erreicht werden. Wo liegt 
die Notwendigkeit der Programmierung mit virtuellen Methoden, wenn das 
gleiche Ergebnis auch mit konventioneller Programmierung erreicht werden 
kann? 


Der Unterschied wird klar, wenn wir verlangen, daß der Kellerspeicher Da- 
tenelemente verschiedener Typen verwalten soll. Für die verschiedenen Ty- 
pen soll Dosomething verschiedene Prozeduren aufrufen. Eine Möglichkeit zur 
Implementierung ist die Einführung einer case-Anweisung in DoSomething, in 
der ein spezieller Prozeduraufruf für jeden Datentyp untergebracht wird. De- 
finiert der Anwender einen neuen Datentyp, muß die case-Anweisung ent- 
sprechend erweitert und Dosomething einen neuen Prozedurparameter erhalten. 
Dieser Ansatz kann dem Anspruch auf datenunabhängige Implementierung 
des Kellerspeichers nicht genügen. Es bleibt praktisch nur die Möglichkeit, 
die Adresse der jeweils aufzurufenden Prozedur mit im Kellerspeicher zu 
verwalten. Das folgende Listing zeigt eine Implementierung dieses Ansatzes. 


120 7 Virtuelle Methoden 


unit StackU3; 


interface 

type ProcT = procedure( P : pointer ); 

type DataElmT = record 
Proc : ProcT; 
DataP : pointer; {-- Zeigt auf Nutzerdaten } 
end; 

const MaxEntriesC = 10; 

type StackT = record 
Buffer : array[ 1..MaxEntriesC ] of DataElnT; 
Index : integer; 
end; 


procedure DoSomething( var Stack : StackT ); 
implementation 


procedure DoSomething( var Stack : StackT ); 
var I : integer; 
begin 
for I:= 1 to Stack.Index do 
with Stack.Buffer[ I ]J do 
Proc( DataP ); 
end; {-- DoSomething } 


end. 


DoSomething hat nun einen Parameter weniger, denn die Prozedurvariable wird 
im Kellerspeicher selber mitgeführt. Die nicht gezeigte Prozedur push muß 
nun aber einen Parameter mehr haben, denn der Anwender muß beim Able- 
gen eines Datenelementes nun angeben, welche Arbeitsprozedur von 
DoSomething für das übergebene Datenelement aufgerufen werden soll. 


Bereits hier sieht man, daß die Lösung des Problems mit objektorientierter 
Programmierung wesentlich übersichtlicher und einfacher ist. Ein weiteres 
Manko des konventionellen Ansatzes ist die fehlende Fehlerprüfung, z.B. bei 
nicht oder falsch initialisierten Prozedurvariablen. Die Fehlerprüfung müßte 
durch den Programmierer explizit implementiert werden. Bei der Lösung mit 
objektorientierter Programmierung werden diese Prüfungen vom Turbo-Pas- 
cal automatisch durchgeführt, wenn der Schalter $R eingeschaltet ist. 


7.12 Ein Blick hinter die Kulissen 


Im Prinzip kann das Ergebnis objektorientierter Programmierung mit virtu- 
ellen Methoden auch durch die Verwendung von Prozedurvariablen erreicht 
werden. Intern bildet der Compiler Aufrufe von virtuellen Methoden mit ei- 
ner ähnlichen Technik ab. 


7.12 Ein Blick hinter die Kulissen 121 


Für jedes Objekt mit virtuellen Methoden, Konstruktoren oder Destruktoren 
legt der Compiler im Datensegment eine Tabelle, die sog. Virtual Methods 
Table oder VMT an. Im ersten Wort der VMT steht die Größe des Datenbe- 
reiches dieses Objekts, im zweiten Wort steht ebenfalls die Größe, jedoch als 
negative Zahl. Diese Redundanz wird von internen Prüfroutinen verwendet, 
um die korrekte Initialisierung einer Instanz zur Laufzeit zu verifizieren. Die 
folgenden Einträge enthalten für jede virtuelle Methode des Objekts einen 
32-bit Zeiger zum Einsprungpunkt der Methode. 


Zusätzlich erweitert der Compiler den Datenbereich eines Objekts mit VMT 
um eine 16-bit Größe, das sog. VMT-Feld. Dieses Feld nimmt später die 
Adresse der zugehörigen VMT auf. Da dem VMT-Feld kein Pascal-Bezeich- 
ner im Datenbereich entspricht, ist es dem Programmierer nicht direkt zu- 
gänglich. Das VMT-Feld wird sofort nach dem Datenbereich des Objekts an- 
geordnet. Wird eine virtuelle Methode, ein Konstruktor oder Destruktor ver- 
erbt, wird auch das VMT-Feld des Vorgängers vererbt. Betrachten wir als 
Beispiel die folgende Objekthierarchie: 


type AT = object 
AVar : integer; 


procedure Proci( X, Y : word ); 
end; {-- AT ) 


type BT = object( AT ) 
BVar : integer; 


constructor Make; 

procedure Proci( X, Y, Start : word ); virtual; 
procedure Proc2; virtual; 

end; {-- BT )} 


type CT = object( BT ) 
CVar : integer; 


procedure Proci( X, Y, Start : word ); virtual; 
procedure Proc3; virtual; 
end; {-- CT } 


In der folgenden Zeichnung der Datenbereiche von at, sr und cr bedeutet je- 
des Rechteck ein Datenwort. 
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AT BT CT 


BVar 


VMT-Feld 


Bild 7-1 : Layout der Datenbereiche der Objekte 


VMT-Feld 


Da gt zum ersten Mal virtuelle Methoden (bzw. einen Konstruktor) definiert, 
wird das VMT-Feld im Datenbereich nach svar angeordnet. cr erbt dieses 
Feld und definiert zusätzlich cvar. 


Die VMTs der drei Objekte haben folgende Form (kleine Rechtecke bedeuten 
ein Wort, große zwei Worte): 


VMT für BT VMT für CT 


$FFFA $FFF8 


oBT.Proci oCT.Proc1 


oBT.Proc2 oBT.Proc2 


oCT.Proc3 


Bild 7-2 : VMT-Layout 


Beachten Sie bitte, daß in den VMTs für sr und cr gleiche Prozedurnamen 
auch gleiche Offsets haben, egal ob die Methoden vererbt oder redefiniert 
wurden. proc2 wird an ct vererbt, daher steht an der entsprechenden Stelle in 
der VMT von cr die Adresse von BT.Proc2. 


Die Verbindung zwischen dem VMT-Feld einer Instanz und der VMT des 
zugehörigen Objekts wird zur Laufzeit durch einen Konstruktor des Objekts 
durchgeführt. In der obigen Objekthierarchie erbt cr den Konstruktor von gr. 
Es ist deshalb nicht möglich, daß der Initialisierungsteil eines Konstruktors 
die VMT-Adresse seines Objekts enthält. Instanzen von cr würden sonst mit 
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der VMT von gr initialisiert. Vielmehr ist es erforderlich, die Adresse der 
jeweiligen VMT als zusätzlichen Parameter an den Konstruktor zu überge- 
ben. 


Zur Übergabe dieses Wertes besitzen Konstruktoren vor dem seıf-Parameter 
einen zusätzlichen, versteckten Parameter vom Typ word. Da Konstruktoren 
selbst nicht virtuell sein können, ist bei der Übersetzung eines Konstruktors 
das zugehörige Objekt eindeutig bestimmt. Der Compiler kann deshalb die 
Adresse der VMT dieses Objekts als Konstante in diesem zusätzlichen Para- 
meter übergeben. Bei der Ausführung des Konstruktors zur Laufzeit kann 
das VMT-Feld der Instanz immer richtig besetzt werden, auch wenn der 
Konstruktor vererbt wird. Für Instanzen von Objekten mit virtuellen Metho- 
den, Konstruktoren oder Destruktoren ist deshalb immer der Aufruf eines 
Konstruktors erforderlich, auch wenn der Konstruktor keine Pascal-Anwei- 
sungen enthält. 


In Turbo-Pascal 5.5 wurde der Compilerschalter $R um die Funktion "VMT- 
Prüfung" erweitert. Ist der Schalter aktiviert, fügt der Compiler vor jedem 
Aufruf einer virtuellen Prozedur einen Sprung zu einer Prüfungsroutine ein. 
Diese Routine prüft, ob das erste Wort der VMT ungleich Null und die 
Summe der ersten beiden Worte der VMT gleich Null ist. Liefert eine der 
beiden Prüfungen ein falsches Ergebnis, wird der Laufzeitfehler error 210: 
Object not initialized ausgelöst. 


Der große Augenblick kommt, wenn eine virtuelle Methode aufgerufen wird. 
Bei der Übersetzung eines Aufrufes einer virtuellen Methode codiert der 
Compiler nicht einen Sprung zu einer festen Adresse, sondern zu einer 
Adresse, die sich aus dem festen Offset in einer VMT ergibt. Ist die Instanz 
richtig initialisiert, steht die Adresse der VMT im VMT-Feld der aktuellen 
Instanz. Je nachdem, zu welchem Objekt die Instanz gehört, wird dann die 
richtige Methode aufgerufen. 


Eine Voraussetzung dazu ist, daß Adressen vom Methoden gleichen Namens 
auch an gleichen Offsets in der VMT abgelegt werden. Der Compiler stellt 
dies beim Aufbau der VMT zur Übersetzungszeit sicher, auch dann, wenn in 
abgeleiteten Objekten die virtuellen Methoden in einer anderen Reihenfolge 
definiert werden. 


Beachten Sie bitte, daß auch dann eine VMT angelegt werden kann, wenn ein 
Objekt keine virtuellen Methoden definiert. Zur Anlage einer VMT reicht die 
Definition eines Konstruktors oder Destruktors aus. Die VMT enthält dann 
keine Einträge für virtuelle Methoden, sondern nur die beiden Felder für die 
Größe der aktuellen Instanz. 
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7.13 Die Funktion SizeOf 


Bis zur Version 5.0 von Turbo-Pascal lieferte die Funktion sizeof die dekla- 
rierte Größe eines Typs oder einer Variablen. Wird sizeof auf eine Instanz 
eines Objekts mit einer VMT angewendet, wird als Ergebnis die aktuelle 
Größe der Instanz zurückgeliefert. 


type AT = object 
AVar : integer; 


constructor Make; 


end; {-- AT ) 
APT = AT; 
type BT = object( AT ) 
BVar : string; 
end; {-- BVar } 
BPT = ’BT; 


constructor AT.Make; begin end; 


var AP : APT; 
BP : BPT; 
begin 


New( AP, Make ); 
New( BP, Make ); 


Writelnt Sizeof( AP“ ) ); 
AP:= BP; 
Writelnt Sizeof( AP’ ) ); 


end. 


In diesem Beispiel haben at und sr zwar keine virtuellen Methoden, aber 
einen Konstruktor. Dies bewirkt, daß für beide Objekte eine VMT angelegt 
wird. Das Programm liefert als Ergebnis die Werte 4 und 260. Dies zeigt, 
daß sizeofc ar ) die aktuelle und nicht die deklarierte Größe der Instanz lie- 
fert. Die Datenbereiche der beiden Objekte sind jedoch nur 2 bzw. 258 Bytes 
groß. Die zwei zusätzlichen Bytes in jedem Objekt entsprechen dem vom 
Compiler automatisch hinzugefügten VMT-Feld. 


Zum Vergleich ändern wir das letzten Programm so ab, daß keine VMT er- 
zeugt wird: 


type AT = object 
AVar : Integer; 


procedure Make; 
end; {-- AT ) 
APT = "AT; 
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type BT = object( AT ) 
BVar : string; 
end; {-- BVar ) 
BPT = ’BT; 


procedure AT.Make; begin end; 


var AP : APT; 
BP : BPT; 


begin 


New( AP ); 
New( BP ); 


Writeln( Sizeof( AP’ ) ); 
AP:= BP; 
Writeln( Sizeof( AP’ ) ); 


end. 


Die Programmausführung liefert als Ergebnis für beide sizeof-Anweisungen 
den Wert 2. Dies entspricht der deklarierten Größe des Basistyps von ar. 


7.14 Die Funktion TypeOf 


Typeof ist eine mit der Version 5.5 neu hinzugekommene Funktion vom Typ 
pointer. Typeof kann nur auf eine Instanz eines Objekts mit einer VMT ange- 
wendet werden. Als Ergebnis wird ein Zeiger auf die VMT zurückgeliefert. 
Meist wird die Typeof-Funktion dazu verwendet, verschiedene Instanzen da- 
raufhin zu prüfen, ob sie Instanzen des gleichen Objekts sind. 


type AT = object 
AVar : Integer; 


constructor Make; 
end; {-- AT } 


APT = "AT; 
type BT = object( AT ) 
BVar ı string; 


end; {-- BVar ) 
BPT = "BT; 
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constructor AT.Make; begin end; 


var AP : APT; 
BP : BPT; 
begin 


New(C BP, Make ); 


AP:= BP; 
writeln( TypeOf( AP“ ) = TypeOf( BP“ ) ); 


end. 


Obwohl ar und sp verschiedenen Basistypen haben, liefert der Vergleich 
TRUE. 


Das Argument von Typeof muß immer ein Bezeichner sein, der vom Typ 
eines Objekts mit einer VMT ist. Das folgende Programm ist syntaktisch 
nicht korrekt: 


type AT = object 
AVar : integer; 
end; {-- AT ) 
APT = AT; 
type BT = object( AT ) 
BVar : string; 


constructor Make; 
end; {-- BVar } 
BPT = ’BT; 


constructor BT.Make; begin end; 


var AP : APT; 
BP : BPT; 
begin 


New( BP, Make ); 


AP:= BP; 
Writeln( TypeOf( AP* ) = TypeOf( BP“ ) ); 


end. 


In diesem Programm hat at keine VMT. Obwohl nach der Zuweisung aPr:= 8P 
der Zeiger ap auf eine Instanz mit VMT-Feld zeigen würde, bricht der Com- 
piler die Übersetzung dieses Programms beim Ausdruck Typeofc at ) mit der 
etwas irreführenden Meldung Error 147: Object type expected ab. Es kommt 
bei der Verwendung von sizeof nur auf die Deklaration des Arguments, nicht 
unbedingt auf seinen aktuellen Wert an. 
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8 Ein verbessertes 
Fenstersystem 


In diesem Kapitel wird das Fenstersystem aus Kapitel 6 erweitert. Wir wer- 
den dabei von den mächtigen neuen Sprachmitteln wie z.B. virtuellen Me- 
thoden Gebrauch machen, um die Probleme des ursprünglichen Fen- 
stersystems zu vermeiden. 


8.1 Aufgabenstellung 


Unser Ziel ist es, ein Gerüst für eine Bibliothek von Fensterfunktionen an- 
zugeben, die der Nutzer nach seinen Wünschen erweitern kann. "Erweitern" 
wird hier in zweifacher Hinsicht verstanden: Einmal kann der Leser natürlich 
den Quelltext der Unit verändern und so die Funktionalität des Fenstersy- 
stems seinen Wünschen anpassen. Zum anderen aber soll es möglich sein, 
daß auch ein Nutzer, der keinen Zugriff auf den Quellcode hat, eigene Er- 
weiterungen hinzufügen kann. 


Eine weitere Forderung, die wir an die fertige Unit stellen, ist, daß der Nut- 
zer einzelne Funktionen redefinieren kann, ohne die Unit neu übersetzen zu 
müssen. So soll es z.B. möglich sein, die Standard-Fehlerbehandlung durch 
eine im Anwenderprogramm definierte Fehlerbehandlung zu ersetzen. 


Die Unit window wird wieder eine Objekthierarchie mit den schon bekannten 
Fensterobjekten BasewndT, Wnd1T und wndet implementieren. Neu hinzugekom- 
men ist das Objekt wndsystemt, das neben Routinen zur Verwaltung von meh- 
reren Fenstern auch die Methode zur Fehlerbehandlung enthält. 


Die Funktionalität der Unit entspricht bis hierhin der des in Kapitel 6 vorge- 
stellten Fenstersystems. Im neuen Fenstersystem kann jedoch durch den Ein- 
satz virtueller Methoden auf die Statusvariable und das damit zusammenhän- 
gende Objekt PreßBasewndt verzichtet werden. An neuen Funktionen bietet die 
Unit window vor allem eine Routine zum Verschieben von Fenstern auf dem 
Bildschirm. Die Verschiebe-Methode steht stellvertretend für den allgemei- 
nen Fall einer Arbeitsprozedur, die auf Fensterobjekten der Objekthierarchie 
arbeitet. Am Beispiel der Verschiebe-Methode wird gezeigt, wie solche Ar- 
beitsprozeduren auch auf Fenstertypen arbeiten, die erst im Anwenderpro- 
gramm definiert werden. 
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8.2 Das Basisfensterobjekt BaseWndT 


type BaseWndT = object( StackElmT ) 
WXMin, WXMax, 
WYMin, WYMax : integer; 
XCur, YCur : integer; (-- Cursorposition im Fenster } 
Status : WndStatusT; 
SaveP : LongArrayPT; {-- gesicherter Bildschirmbereich } 
ColCount, LineCount : integer; 
Amount : integer; 


constructor Make( XMin, XMax, YMin, YMax : integer ); 
destructor Kill; virtual; 


procedure Allocate; virtual; 
procedure Activate; virtual; 
procedure DeActivate; virtual; 
procedure DeAllocate; virtual; 


procedure Open; 
procedure Close; 
end; (-- BaseWndT } 


BaseWndPT = *BaseWndT; 


Im Definitionsteil des Basisfensterobjekts Basewndt sind die Methoden open 
und Close in die Methoden Allocate und Activate DZW. DeActivate und DeAllo- 
cate differenziert worden. Diese Trennung bringt Vorteile, wenn mehrere 
parallele, d.h. sich nicht überdeckende Fenster geöffnet werden sollen. 


Die vier Methoden Allocate, Activate, DeActivate und DeaAllocate Sind alle vir- 
tuell. Da von Basewndt abgeleitete Objekte im allgemeinen zusätzliche Para- 
meter benötigen, kann die Methode zur Übergabe der Parameter nicht virtu- 
ell sein, denn virtuelle Methoden müssen identische Parameterlisten aufwei- 
sen. Die hier gewählte Lösung verwendet den Konstruktor Make zur Übergabe 
der Parameter an das Objekt. Alle anderen Methoden benötigen keine Para- 
meter mehr. 


Basewndt definiert zusätzlich noch open- und Close-Methoden, die jedoch nur 
Allocate und Activate DZW. DeActivate und DeAllocate aufrufen. 


BaseWndt ist das Urfensterobjekt in der Hierarchie, von dem die anderen Fen- 
sterobjekte abgeleitet werden. Es dient außerdem als Basistyp zur Deklara- 
tion von Zeigern auf Instanzen von Fensterobjekten. Aufgrund der erweiter- 
ten Zuweisungskompatibilität in Objekthierarchien können Zeigern vom Typ 
BaseWndpT auch Instanzen aller Nachfolger von Basewndt zugewiesen werden. 


Die einzelnen Methoden in Basewndt haben folgende Aufgaben: 
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8.2.1 Make 


Da virtuelle Methoden verwendet werden, ist ein Konstruktor erforderlich. 
Da ein Konstruktor selber nicht virtuell sein kann, eignet er sich zur Über- 
gabe von Parametern an das Objekt. Die übergebenen Parameter werden auf 
Zulässigkeit geprüft und im Datenbereich des Objekts abgelegt. 


8.2.2 Allocate 


Aufgrund der im Datenbereich abgelegten gewünschten Fenstergröße be- 
rechnet Allocate die erforderliche Speichermenge, fordert den Speicher vom 
Heap an und legt den Bildschirminhalt unter dem zukünftigen Fenster dort 
ab. 


8.2.3 Activate 


Activate Schließlich definiert mittels der crt-window Prozedur das Fenster. Das 
Fenster ist nun aktiv, Ausgaben mit write bzw. writeln sind auf den Bereich 
des Fensters beschränkt. Activate setzt den Cursor auf die Stelle, an der er 
beim Deaktivieren des Fensters stand, bzw. an den linken, oberen Rand, 
wenn das Fenster noch nicht aktiv war. 


8.2.4 DeActivate 


Die Methode deaktiviert ein Fenster, ohne den darunterliegenden 
Bildschirminhalt wiederherzustellen. Nun kann z.B. ein anderes Fenster akti- 
viert werden. DeActivate speichert die momentane Cursorposition im Da- 
tenbereich des Objekts. Bei einem späteren Aufruf von Activate kann so die 
ursprüngliche Cursorposition vor dem Deaktivieren wiederhergestellt wer- 
den. 


8.2.5 DeAllocate 


DeAllocate Stellt den unter dem Fenster befindlichen Bildschirminhalt wieder 
her und gibt den zur Speicherung erforderlichen Speicher wieder frei. 


8.2.6 Kill 


Der Destruktor enthält keine für das Fenstersystem wesentlichen Anweisun- 
gen. Ein Destruktor erleichtert jedoch die korrekte Speicherverwaltung bei 
dynamischen Objekten. 
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Die Implementierung der Methoden ist in der Datei W100 zusammengefaßt. 


constructor BaseWndT.Make( XMin, XMax, YMin, YMax : integer ); 


begin WndSystemP“.DoFirst; 
Status:= NotInitialized; 


{-- RangeCheck der Parameter --) 

if C XMin < 1 ) or ( XMax > ScrColumnsC ) or 
( YMin < 1 ) or ( YMin > ScrLinesC ) then 
begin 
WndSystemP“.WndError( WndWrongParam ); 
exit; 
end; 


{-- Fenster muss mindestens 1x1 gross sein --) 
if C XMax - XMin < 2 ) or ( YMax - YMin < 2 ) then 
begin 
WndSystemP“.WndError( WndTooSmall ); 
exit; 
end; 


{-- Fensterkoordinaten speichern -- } 
WXMin:= XMin; WXMax:= XMax; 
WYMin:= YMin; WYMax:= YMax; 


Status:= Made; 
end; {-- Make ) 


procedure BaseWndT .Allocate; 
var I, J : integer; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --) 
if not ( Status in [ Made, DeAllocated ] ) then 
begin 
WndSystemP”“.WndError( WndWrongStat ); 
exit; 
end; 


{-- Feststellen des zu sichernden Bildschirmbereiches --) 
ColCount:= 2*succ( WXMax-WXMin ); {-- bytes pro Zeile } 
LineCount:= succ( WYMax-WYMin ); {-- Anzahl Zeilen ) 
Amount:= LineCount * ColCount; 


{-- hier waere die Verwendung von Fail moeglich, diese Loesung ist 
aber besser, da ein spezifischer Fehlercode erzeugt wird } 


if MaxAvail < Amount then 
begin 
WndSystemP“.WndError( WndNoMem ); 
exit; 
end; 


GetMem( SaveP, Amount ); 
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{-- Zeilenweise in SaveP”“ ablegen --) 


J:= 1; 
for I:= WYMin to WYMax do 
begin 


move( ScreenP”“[ I, WXMin ], SaveP“[ J ], ColCount ); 
J:= J + ColCount; 


Status:= Allocated; 
end; {-- Allocate } 


procedure BaseWndT.Activate; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --} 
if not ( Status in [ Allocated, DeActive ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


£-- Fenster oeffnen und Cursor auf letzte Position --} 
ert.Window( WXMin, WYMin, WXMax, WYMax ); 
gotoXY(C XCur, YCur ); 


Status:= Active; 
end; {-- Activate ) 


procedure BaseWndT.DeActivate; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --} 
if Status <> Active then 
begin 
WndSystemP”.WndError( WndWrongStat ); 
exit; 
end; 


XCur:= WhereX; YCur:= WhereY; 
ert.Window( 1, 1, ScrColumnsC, ScrLinesC ); 


Status:= DeActive; 
end; (-- DeActivate } 
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procedure BaseWndT .DeAllocate; 
var I, J : integer; 
begin WndSystemP”“.DoFirst; 


{-- Statuspruefung --) 
if not ( Status in [ Allocated, DeActive ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


{-- Zeilenweise aus SaveP”“ holen --) 
J:= 1; 
for l:= WYMin to WYMax do 
begin 
move( SaveP”[ J ], ScreenP”“L[ I, WXMin ], ColCount ); 
:= J + ColCount; 
end; 


FreeMem( SaveP, Amount ); 
Status:= DeAllocated; 
end; (-- DeAllocate } 


destructor BaseWndT .Kill; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --) 
if not ( Status in [ Made, DeAllocated ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


end; {-- Kill ) 


procedure BaseWndT.Open; 
begin WndSystemP”“.DoFirst; 
Allocate; 

Activate; 

end; {-- Open } 


procedure BasewWndT.Close; 
begin WndSystemP”“.DoFirst; 
DeActivate; 

DeAllocate; 

end; {-- Close } 


Im Vergleich mit der ursprünglichen Implementierung aus Kapitel 6 fällt vor 
allem der Aufruf der Prozedur borirst als erste Anweisung einer jeden Me- 
thode auf. DoFirst ist im Objekt wndsystemt definiert. Die Aufgabe von Dorirst 
werden wir später behandeln. Ebenfalls verändert wurde die Fehlerbehand- 
lung. Diese wird nun von der Prozedur wnderror durchgeführt, die ebenfalls 
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in Wndsystemt definiert ist. Im Fehlerfalle wird die gerade aktive Methode 
grundsätzlich verlassen. 

Die verschiedenen Methoden können nicht in jeder beliebigen Reihenfolge 
aufgerufen werden. Der Programmteil Statusprüfung in den Methoden stellt 
über die Variable status sicher, daß diese Reihenfolge eingehalten wird. Das 
Bild 8-1 zeigt die möglichen Abfolgen. 


Allocate 


DeActivate 
DeAllocate 


Bild 8-1 : Zulässige Aufrufreihenfolgen 


134 8 Ein verbessertes Fenstersystem 


8.3 Das Objekt Wndi1T 


Ein Fenster vom Typ wndit besitzt einen Rahmen, der je nach Status des Fen- 
sters unterschiedlich sein kann. Die zwei vorhandenen Rahmentypen werden 
verwendet, um ein aktives von einem nicht aktiven Fenster zu unterscheiden. 
Der Aufruf der zwei Rahmenprozeduren wird deshalb in Activate bzw. 
DeActivate durchgeführt. Activate und DeActivate müssen daher redefiniert 
werden, die restlichen Methoden des Basisfensters werden geerbt. 


type WndiT = object( BaseWndT ) 
WName : WNameT; 
FrameType : ( Standard, Alternate ); 
constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 
procedure Activate; virtual; 
procedure DeActivate; virtual; 


procedure SetStandard; 
procedure SetAlternate; 


end; {-- Wnd1T > 


WndiPT = “yWndiT; 


Datei W101 


constructor Wndi1T.Make( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 
begin WndSystemP“.DoFirst; 


if XMax > ScrColumsC - 2 then 
begin 
WndSystemP”.WndError( WndWrongParam ); 
exit; 
end; 


BaseWndT.Make( pred( XMin ), succ( XMax ), pred( YMin ), succ( YMax ) ); 


{-- Namen speichern --) 
WName:= Name; 


FrameType:= Alternate; 
end; {-- Make ) 


procedure Wnd1T.Activate; 
begin WndSystemP”“.DoFirst; 
BaseWndT .Activate; 
SetAlternate; 

end; (-- Activate )} 
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procedure Wnd1T.DeActivate; 
begin WndSystemP“.DoFirst; 
SetStandard; 

BaseWndT .DeActivate; 

end; 


procedure Wnd1T.SetStandard; 


var | : integer; 
XSpan, YSpan : integer; 
DspName : WNameT; 
var SaveCurX, SaveCurY : integer; 


begin WndSystemP“.Dofirst; 


{-- Cursor Sichern, am Ende der Prozedur wiederherstellen } 
SaveCurX:= WhereX; SaveCurY:= WhereY; 


ert.Window( WXMin, WYMin, succ( WXMax ), WYMax ); 


XSpan:= succ( WXMax - WXMin ); (-- Spaltenzahl } 
YSpan:= succ( WYMax - WYMin ); {-- Zeilenzahl } 


gotoXY( 1, 1); 

write( UpperlLeftiC ); 

for I:= 2 to pred( XSpan ) do 
write(C HorizontaliC ); 

write(C UpperRightiC ); 


for I:= 2 to pred( YSpan ) do 
begin 
gotoXY( 1, 1); 
write( VerticaliC ); 
gotoXY( XSpan, I ); 
write( VerticaliC ); 
end; 


gotoXY( 1, YSpan ); 

write( LowerLeftiC ); 

for I:= 2 to pred( XSpan ) do 
write( HorizontaliC ); 

write( LowerRightiC ); 


{-- Namen eintragen --) 

DspName:= copy( WName, 1, XSpan-2 ); {-- Maximale Laenge ist XSpan-2 } 
gotoXY( succ( trunc( succ( XSpan )/2 - length( DspName )/2 ) ), 1); 
write( DspName ); 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
gotoXY( SaveCurX, SaveCurY ); 


end; {-- SetStandard } 
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procedure Wnd1T.SetAlternate; 


var I : integer; 
XSpan, YSpan : integer; 
DspName : WNameT; 
var SaveCurX, SaveCurY : integer; 


begin WndSystemP“.DoFirst; 


{-- Cursor Sichern, am Ende der Prozedur wiederherstellen } 
SaveCurX:= WhereX; SaveCurY:= WhereY; 


crt.Window( WXMin, WYMin, succ( WXMax ), WYMax ); 


succ( WXMax - WXMin ); C-- Spaltenzahl } 
succ( WYMax - WYMin ); {-- Zeilenzahl } 


XSpan:= 

YSpan:= 

gotoXY( 1, 1); 

write( UpperlLeft2C ); 

for I:= 2 to pred( XSpan ) do 
write( Horizontal2C ); 

write( UpperRight2C ); 


for I:= 2 to pred( YSpan ) do 
begin 
gotoXY( 1, 1); 
write( Vertical2C ); 
gotoXY( XSpan, I ); 
write( Vertical2C ); 
end; 


gotoXY( 1, YSpan ); 

write( Lowerleft2C ); 

for Il:= 2 to pred( XSpan ) do 
write( Horizontal2C ); 

write(C LowerRight2C ); 


{-- Namen eintragen --} 

DspName:= copy( WName, 1, XSpan-2 ); (-- Maximale Laenge ist XSpan-2 )} 
gotoXYC succ( trunc( succ( XSpan )/2 - length( DspName )/2 ) ), 1); 
write( DspName ); 


cert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
gotoXY( SaveCurX, SaveCurY ); 


end; (-- SetAlternate } 
Die Implementierung der Methoden Activate und DeActivate zeigt deutlich, 


wie das neue Objekt wndır auf die bereits im Basisfenster implementierte 
Funktionalität aufbaut. 
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8.4 Das Objekt Wnd2T 


Das Objekt under implementiert die Exploding Windows aus Abschnitt 6.2 
Das Öffnen eines Fensters geschieht hierbei nicht schlagartig, sondern - aus- 
gehend von einem Ursprungspunkt - in einem kontinuierlichen Prozess. 
Analog wird das Schließen zu diesem Punkt hin durchgeführt. Die dazu er- 
forderlichen Verarbeitungsschritte sind in den Methoden Attocate und DeAllo- 
cate implementiert. Für bestimmte Anwendungen kann es günstiger sein, das 
Öffnen und Schließen in gesonderte Methoden zu verlegen. 


type Wnd2T = object( WndiT ) 
WXStart, WYStart : integer; 


constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT; 
XStart, YStart : integer ); 

procedure Allocate; virtual; 

procedure DeAllocate; virtual; 


end; {-- Wnd2T } 


Wnd2PT = AWnd2T; 
Datei W102 


constructor Wnd2T.Make( XMin, XMax, YMin, YMax : integer; Name : WNameT; 
XStart, YStart : integer ); 
begin WndSystemP”“.DoFirst; 


{-- RangeCheck Parameter --} 

if ( XStart < 2 ) or ( YStart < 2 ) then 
begin 
WndSystemP”“.WndError( WndWrongStart ); 
exit; 
end; 


WXStart:= XStart; 
WYStart:= YStart; 


Wnd1T.Make( XMin, XMax, YMin, YMax, Name ); 
end; (-- Make } 
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procedure Wnd2T.Allocate; 


var XMinDelta, XMaxDelta, 
YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 
TempYMin, TempYMax : 


var Done 


D 


var TempW 
begin WndSystemP“.DoFirst; 


XMinDelta: 
XMaxDelta: 
YMinDbelta: 
YMaxDelta: 


TempXMin:= 
TempXMax:= WXStart 
TempYMin:= WYStart 
TempYMax:= WYStart 


WXStart 


+ 
+ 
+ 
+ 


Sign( succ( WXMin ) 
Sign( pred( WXMax ) 
Sign( succ( WYMin ) 
Sign( pred( WYMax ) 


XMinDelta; 
XMaxDelta; 
YMinDelta; 
YMaxDelta; 


TempW.Make( TempXMin, TempXMax, 
TempW.Open; 

Done:= false; 
D:= 20; 


while 


not 


begin 
Done: = 


Delay( 
D:= 0; 
TempW.Close; 
TempW.Kill; 


{-- Neue Koordinaten berechnen --} 


Done do 
true; 


D) 
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integer; 


boolean; 
integer; 


Wnd1T; 


- WXStart ); 
- WXStart ); 
- WYStart ); 
- WStart ); 


TempYMin, TempYMax, WName ); 


if TempXMin <> succ( WXMin ) then 


if 


inc( TempXMin, XMinDelta ); 


TempXMax <> pred( WXMax ) then 


TempXMax, XMaxDelta ); 


begin 

inc D, 5); 

Done:= false; 
end; 

begin 

inc( 

inc D,5); 

Done:= false; 


end; 
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if TempYMin <> succ( WYMin ) then 


begin 

inc( TempYMin, YMinbel 
inc D, 5); 

Done:= false; 

end; 


if TempYMax <> pred( WYMax ) then 


begin 

inc( TempYMax, YMaxDel 
incl D, 5); 

Done:= false; 

end; 


TempW.Make( TempXMin, TempXMax, TempYMin, TempYMax, WName ); 


TempW .Open; 
end; {-- while not Done } 


{-- Temporaeres Fenster befindet sich jetzt an der Stelle 
des aktuellen Fensters. Temp loeschen und aktuelles Fenster oeffnen } 


TempW.Close; 
TempW.Kill; 
wWnd1T.Allocate; 


end; {-- Allocate } 


procedure Wnd2T.DeAllocate; 


var XMinDelta, XMaxDelta, 
YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 
TempYMin, TempYMax 


var Done 
D 


var TempW 
begin WndSystemP”“.DoFirst; 
XMindelta:= Sign( WXStart - 


XMaxDelta:= Sign( WXStart - 
YMindelta:= Sign( WYStart - 


YMaxDelta:= Sign( WYStart - 
TempXMin:= WXMin; 
TempXMax:= WXMax; 
TempYMin:= WYMin; 
TempYMax:= WYMax; 


Wnd1T.DeAllocate; 
Done:= false; 


ta ); 


ta ); 


: integer; 


: boolean; 
: integer; 


: Wnd1T; 
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while not Done do 
begin 
Done:= true; 
D:= 0; 


if ( TempXMax = TempXMin ) and ( TempYMax = TempYMin ) then 
begin {-- Verschieben --)} 


D:= 20; 

if TempXMin <> WXStart then 
begin 
inc( TempXMin, XMinDelta ); 
inc( TempXMax, XMaxDelta ); 
Done:= false; 
end; 


if TempYMax <> WYstart then 
begin 
inc( TempYMin, YMinbelta ) 
inc( TempYMax, YMaxDelta ) 
Done:= false; 
end; 


end {-- Verschieben } 
else 
begin {-- Verkleinern } 


if C XMinDelta > O0 ) and ( TempXMin <> WXStart ) then 
begin 
if TempXMax - TempXMin > O0 then 
inc( TempXMin, XMinDelta ); 
inc( D,5); 
Done:= false; 
end; 


if C XMaxDelta < O0 ) and ( TempXMax <> WXStart ) then 
begin 
if TempXMax - TempXMin > O then 
inc( TempXMax, XMaxDelta ); 
inc( D,5 ); 
Done:= false; 
end; 


if C YMinDelta > O0 ) and ( TempYMin <> WYStart ) then 
begin 
if TempYMax - TempYMin > O then 
inc( TempYMin, YMinDelta ); 
inc( D,5); 
Done:= false; 
end; 


if C YMaxDelta < O ) and ( TempYMax <> WYStart ) then 
begin 
if TempYMax - TempYMin > O then 
inc( TempYMax, YMaxDelta ); 
inc D, 5); 
Done:= false; 
end; 
end; 
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TempW.Make( TempXMin, TempXMax, TempYMin, TempYMax, WName ); 


TempW.Open; 
Delay( D ); 


TempW.Close; 
TempW.Kill; 
end; {-- while ) 


end; {-- DeAllocate ) 


8.5 Das Objekt WndSystemT 


In wndsystemt sind diejenigen Verarbeitungsschritte zusammengefaßt, die für 
das gesamte Fenstersystem erforderlich sind. Neben Prozeduren zum Ver- 
walten mehrerer übereinanderliegender Fenster ist die Fehlerbehandlung nun 
IN Wndsystemt untergebracht. 


type WndSystemT = object( StackT ) 


{-- ActiveWP zeigt auf das aktuelle Fenster oder ist nil --) 
ActiveWP : BaseWndPT; 


{-- WndOK wird von WndSystemT.WndError besetzt und sollte nach 
jeder Operation mit dem Fenstersystem abgefragt werden. 
Das Zuruecksetzen auf true ist Aufgabe des Nutzerprogramms --} 
WndOK : boolean; 


constructor Make; 


procedure OpenWnd( NewWndP : BaseWndPT ); 
function CloseWnd : boolean; 


procedure RePositionWnd( DeltaX, DeltaY : integer ); 


procedure DoFirst; virtual; 
procedure WndError( ErrorCode : byte ); virtual; 


end; {-- WndSystemT } 
WndSystemPT = *WndSystemT; 


{-- Von WndSystemPT wird sofort eine Variable deklariert } 
var WndSystemP : WndSystemPT; 


8.5.1 Die Fehlerbehandlung 


Tritt während der Ausführung einer Methode des Fenstersystems ein Fehler 
auf, wird die Fehlerbehandlungsmethode wndsystemt.wWndError mit einem ent- 
sprechenden Parameter aufgerufen. Die Fehlerbehandlungsroutine ist im Ge- 
gensatz zur ersten Version des Fenstersystems als virtuelle Methode eines 
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Objekts definiert. Dadurch wird erreicht, daß der Nutzer der Unit durch Re- 
definieren der Methode wnderror in seinem Anwendungsprogramm auf einfa- 
che Weise eine eigene Fehlerbehandlung implementieren kann. Da wnderror 
virtuell ist, rufen dann auch die Methoden der Objekte Basewndt und wnd1T die 
neue Fehlerroutine auf. An der Unit window selber braucht nichts verändert zu 
werden. Diese neue Art der Fehlerbehandlung erfordert jedoch, daß in jedem 
Programm, das Fenster benötigt, eine Instanz von wndsystemt vorhanden und 
richtig initialisiert ist. Wir werden das Thema Fehlerbehandlung in Abschnitt 
8.8 erneut aufgreifen. 


8.5.2 Die Methode DoFirst 


wndsystemt definiert die Methode oorirst, die in (fast) jeder Methode des Fen- 
stersystems als erste Anweisung aufgerufen wird. borFirst selber enthält je- 
doch keine ausführbaren Anweisungen, so daß durch einen Aufruf von Do- 
First nichts bewirkt wird. Der Nutzer kann jedoch vorirst redefinieren. Da 
die Methode virtuell deklariert ist, bewirkt eine Redefinition, daß alle Fen- 
sterroutinen vor ihrer eigentlichen Arbeit die neudefinierte Nutzerprozedur 
aufrufen. Ein solches "Hook" wird von Programmierern gern verwendet, um 
z.B. in der Entwicklungsphase vor der Ausführung der eigentlichen Methode 
die Datenbereiche der Objekte zu überprüfen bzw. gezielt zu verändern. Eine 
andere Anwendungsmöglichkeit besteht darin, die Methoden schrittweise 
ausführen zu lassen. vorirst wird dazu so programmiert, daß die Programm- 
ausführung bis zu einem Tastendruck unterbrochen wird - dies ist eine wert- 
volle Entwicklungshilfe, wenn der Quellcode der Unit nicht zur Verfügung 
steht bzw. das Programm für das Arbeiten mit dem Turbo-Pascal-Debugger 
zu groß ist. Wir werden die Methode borirst verwenden, um die Fehlerbe- 
handlung des Fenstersystems um eine weitere Prüfung zu erweitern. 


8.5.3 Die Methode RePositionWnd 


Mit der Methode Rerositionwnd können Fenster auf dem Bildschirm verscho- 
ben werden. Inhalt und Cursorposition bleiben dabei unverändert. RePositi- 
onwWnd verschiebt immer das aktive Fenster. Zum Verschieben werden keine 
speziellen Methoden der Fensterobjekte verwendet, sondern es reichen die 
vorhandenen Methoden Allocate, Activate, DeActivate Und DeAllocate aus. 
Werden in einem Anwenderprogramm abgeleitete Fensterobjekte definiert, 
können auch diese mit RePositionwnd verschoben werden, ohne daß eine spe- 
zielle Verschiebeprozedur geschrieben werden müßte. 


8.5 Das Objekt WndSystemT 143 


8.5.4 Quellcode des Objekts WndSystemT 


Das folgende Listing zeigt den Quellcode der Definition und Implementie- 
rung des Objekts wndsystemT. 


constructor WndSystemT .Make; 
begin 

StackT ..Make; 

ActiveWP:= nil; 

WndOK:= true; 


ScreenPp:= ptr( GetScreenBase, 0 ); 
end; {-- Make } 


procedure WndSystemT.OpenWnd( NewWndP : BaseWndPT ); 
begin DoFirst; 


if ActiveWP <> nil then 

begin 

ActiveWP“.DeActivate; 

if not Push( ActiveWP ) then 
begin 
WndError( WndStackFull ); 
exit; 
end; 

end; 


ActiveWP:= NewWndP; 

ActiveWP“.Open; 

end; {-- OpenWnd } 

function WndSystemT.CloseWnd : boolean; 
var WorkWP : BaseWndPT; 
begin DoFirst; 


if ActiveWP = nil then 


begin 

CloseWnd:= false; 

exit; 

end; 
ActiveWP“.Close; 


dispose( ActiveWP, Kill ); 


ActiveWP:= BaseWndPT( Pop ); 
if ActiveWP <> nil then 
ActiveWP”.Activate; 


CloseWnd:= true; 
end; {-- CloseWnd } 
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procedure WndSystemT.RePositionWnd( DeltaX, DeltaY : integer ); 


var SwapW : BaseWndT; 
SaveXCur, SaveYCur : integer; 


begin DoFirst; 
if ActiveWP = nil then exit; {-- kein Fenster offen } 


{-- Altes Fenster deaktivieren, um Cursorposition zu speichern --)} 
ActiveWP”.DeActivate; 


{-- Temporaeres Fenster zum Zwischenspeichern des aktuellen 
Fensters erzeugen --)} 


with ActiveWP” do 
SwapW.Make( WXMin, WXMax, WYMin, WYMax ); 


(-- Aktuellen Fensterbereich sichern } 
SwapW.Open; 


{-- Auf dem Heap befindet sich jetzt eine Kopie des aktuellen Fensterinhalts } 
(-- Aktuelles Fenster schliessen und an neuen Koordinaten oeffnen --} 


with ActiveWP”“ do 
begin 
DeAllocate; 
inc( WXMin, DeltaX ); 
incl WXMax, DeltaX ); 
inc( WYMin, DeltaY ); 
inc WYMax, DeltaY ); 
SaveXCur:= XCur; SaveYCur:= YCur; 
Allocate; 
XCur:= SaveXCur; YCur:= SaveYCur; 
end; 


{-- nun den gesicherten Bildschirminhalt auf die neuen Koordinaten kopieren } 


with SwapW do 
begin 
inc( WXMin, DeltaX ); 
inc( WXMax, DeltaX ); 
inc( WYMin, DeltaY ); 
inc( WYMax, DeltaY ); 
Close; 
end; 

SwapW.Kill; 


ActiveWP”.Activate; 
end; {-- RePositionWnd } 


procedure WndSystemT.DoFirst; 
begin 
end; {-- DoFirst } 
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procedure WndSystemT.WndError( ErrorCode : byte ); 
begin 


(-- Standardmaessig wird eine Fehlermeldung ausgegeben und WndOK auf false 
gesetzt --) 


case ErrorCode of 


WndWrongParam : writeln( WndWrongParaml ); 
WndTooSmall : writeln( WndTooSmallC ); 
WndNoMem : writeln( WndNoMemC ); 
WndWrongStat : writeln( WndWrongStatC ); 
WndWrongStart : writeln( WndWrongStartC ); 
WndWrongScroll : writeln( WndWrongScrollC ); 
WndStackEmpty : writeln( WndStackEmptyC ); 
WndStackFull : writeln( WndStackFullt ); 


end; {-- case } 
WndOK:= false; 


end; (-- WndError } 


Die Methode openwnd öffnet nicht mehr selber ein Fenster, sondern erhält als 
Parameter einen Zeiger auf eine Instanz eines Fensters. Damit andere Me- 
thoden des Objekts wnadsystemt das aktuelle Fenster bearbeiten Können, wird 
der Zeiger Activewp auf die übergebene Instanz gesetzt. Ein evtl. vorher akti- 
ves Fenster wird deaktiviert und mit push im Kellerspeicher abgelegt. Umge- 
kehrt schließt Closewnd das aktuelle Fenster, holt mit Pop das nächste Fenster 
aus dem Kellerspeicher (Falls vorhanden) und aktiviert dieses. 


Die Verschiebung eines Fensters läuft in drei Schritten ab. Zuerst wird der 
aktuelle Bildschirminhalt im Fenster in einem Zwischenspeicher gesichert. 
Diese Aufgabe übernimmt das Fenster swapw, das zu diesem Zweck genau 
über dem aktuellen Fenster definiert wird. Im zweiten Schritt wird das aktu- 
elle Fenster geschlossen und an den neuen Koordinaten geöffnet. Zuletzt 
wird noch der gesicherte Fensterinhalt aus swapw an die neue Stelle kopiert. 
Da es nicht erforderlich ist, swapw dynamisch zu erzeugen, wird die Instanz 
als gewöhnliche Variable auf dem Stack definiert. 


Die Methode wnderror ist die Fehlerbehandlungsroutine des Fenstersystems. 
Standardmäßig wird im Fehlerfalle eine entsprechende Meldung ausgegeben 
und die Variable wnaok auf false gesetzt. Der Programmierer kann wndok im 
Anwenderprogramm abfragen, um z.B. falsche Parameter zu korrigieren. 
Die Fehlerkonstanten werden exportiert, um auch in einer redefinierten Feh- 
lerbehandlungsroutine die vordefinierten Meldungen zur Verfügung zu ha- 
ben. 
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8.6 Die vollständige Unit Window 


Die Objekt:DefinitionDefinitionsteile der Objekte werden wieder im 
Objekt:ImplementierungImplementierungen 
Implementierungsteil der Unit window untergebracht. Der für einen Anwender 
wichtige Teil des Quellcodes der Unit ist in der Datei Window 


Interfaceteil 


zusammengefaßt. 


unit window; 


interface 


uses crt, general, VStackU; 
{$1 W101.del 


{-- Fehlerbehandlung --) 


const 


const 


WndWrongPar.am 
WndTooSmall 
WndNoMem 
WndWrongStat 
WndWrongStart 
WndWrongScroll 


WndStackEmpty 
WndStackFull 


WndWrongPar amC 
WndTooSmal IC 
WndNoMemC 
WndWrongStatC 
WndWrongStartC 
WndWrongScrollC 


WndStackEmptyC 
WndStackFullc 


und die 


nn nn ne Sa 


= 


ne. 


oON au rnwWwn- 


u} 


: string[ 
: stringl[ 
: string[ 
: stringl 
: string[ 
: string[l 


: string[ 
: string[ 


17 
16 
18 
15 
18 
18 


26 
25 


ud ud 


> C-- Im InterfaceTeil gebrauchte Deklarationen } 


'Falsche Parameter’; 
'Fenster zu klein’; 
'Kein Speicher mehr’; 
'Falscher Status’; 
'Falsche Startwerte’; 
'Falsche Scrollbars’; 


'Keine offenen Fenster mehr’: 


'Kein Platz mehr auf Stack’; 
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{00-0 BaseWndT --------------- oma neee een B; 
type BaseWndT = object( StackElmT ) 

WXMin, WXMax, 

WYMin, WYMax : integer; 

XCur, YCur : integer; {-- Cursorposition im Fenster ) 

Status : WndStatusT; 

SavePp : LongArrayPT; (-- gesicherter Bildschirmbereich } 


ColCount, LineCount : integer; 
Amount : integer; 


constructor Make( XMin, XMax, YMin, YMax : integer ); 
destructor Kill; virtual; 


procedure Allocate; virtual; 
procedure Activate; virtual; 
procedure DeActivate; virtual; 
procedure DeAllocate; virtual; 


procedure Open; 
procedure Close; 


end; {-- BaseWndT } 


BaseWndPT = *BaseWndT; 

E------- nn WNdIT ===. ------ HH Hmm HH anne nenn } 
type Wnd1T = object( BaseWndT ) 

WName : WNameT; 

FrameType : ( Standard, Alternate ); 

constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 

procedure Activate; virtual; 

procedure DeActivate; virtual; 


procedure SetStandard; 
procedure SetAlternate; 


end; {-- WndiT } 


Wnd1PT = “undiT; 
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[--------..-.- WNd2T _--------------- 4-44 Hann > 
type Wnd2T = object( WndiT ) 

WXStart, WYStart : Integer; 

constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT; 

XStart, YStart : integer ); 

procedure Allocate; virtual; 

procedure DeAllocate; virtual; 

end; {-- Wnd2T } 

Wnd2PT = *WndaT; 

{> - 000. WndSystemT ------------------------ mem - oo eeeeeeenenn > 


type WndSystemT 


object( StackT ) 


{-- ActiveWP zeigt auf das aktuelle Fenster oder ist nil --) 
ActiveWP : BaseWndPT; 


{-- WndOK wird von WndSystemT.WndError besetzt und sollte nach 
jeder Operation mit dem Fenstersystem abgefragt werden. 
Das Zuruecksetzen auf true ist Aufgabe des Nutzerprogramms --) 
WndOK : boolean; 


constructor Make; 


procedure OpenWnd( NewwndP : BaseWndPT ); 
function CloseWnd : boolean; 


procedure RePositionWnd( DeltaX, DeltaY : integer ); 


procedure DoFirst; virtual; 
procedure WndError( ErrorCode : byte ); virtual; 


end; {-- WndStackT } 


WndSystemPT = *WndSystemT; 
var WndSystemP : WndSystemPT; 
implementation 
{$1 W111.del > {-- ScreenT } 

{$1 wW112.del > {-- Konstanten fuer Rahmen } 
{$1 W100 > (-- Methoden BasewWndT } 
{$1 W101 > {-- Methoden Wnd1T > 
{$1 W102 > (-- Methoden Wnd2T > 
{$1 W110 > {-- Methoden WndStackT } 


end. 
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Beachten Sie bitte, daß zur Deklaration der Variablen status, Savep etc. in den 
Datenbereichen der Objekte Typvereinbarungen erforderlich sind, die dem 
Anwender eigentlich nicht zugänglich sein sollten. Die Syntax von Turbo- 
Pascal läßt eine Trennung von globalen und lokalen Deklarationen im Daten- 
bereich von Objekten jedoch nicht zu. Die Typvereinbarungen müssen daher 
im Interfaceteil der Unit angeordnet werden und sind deshalb für den Nutzer 
zugreifbar. Solche Deklarationen sind in die Includedatei W101.dcl ausgela- 
gert worden, um sie zumindest etwas zu verstecken. 


Die Dateien W100, W101, W102 und W110 enthalten die Implementierun- 
gen der Objekte. Der Quelltext ist in den Abschnitten 8.2.1 bis 8.2.6 ange- 
geben und wird deshalb nicht erneut abgedruckt. Die Dateien W111.dcl und 
W112.dcl haben sich gegenüber dem ursprünglichen Fenstersystem aus Ka- 
pitel 6 nicht verändert. Sie werden der Vollständigkeit halber hier noch ein- 
mal angegeben. 


Datei W111.dcl 


{-- Interpretation eines Hauptspeicherbereiches als Bildschirmspeicher } 


const ScrColumnsC 80; {-- Spalten pro Zeile )} 


ScrLinescC 25; (-- Bildschirmzeilen } 
type ScrCharT = record 
Ch : char; {-- Das eigentliche Zeichen } 
Attr : byte; (-- Attribut des Zeichens )} 


end; {-- ScrCharT } 


type ScrLineT arrayl[l 1..ScrColumsC ] of ScrCharT; 


*ScreenT; 
arrayl 1..ScrLinesC ] of ScrLineT; 


type ScreenPT 
ScreenT 


{-- ScreenP zeigt auf Hardwarebildschirm. Wird im Initialisierungsteil 
von Window initialisiert --} 


var ScreenP : ScreenPT; 
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Datei W112.dcl 


{-- Konstanten fuer Rahmen und Scrollbars etc --) 


(-- Einfacher Rahmen --} 


const UpperLeftiC = #218; 
LowerLeftiC = #192; 
UpperRightiC = #191; 
LowerRightiC = #217; 
VerticaliC = #179; 
HorizontaliC = #196; 

{-- Doppelter Rahmen --} 

const UpperLeft2C = #201; 
LowerLeft2C = #200; 
UpperRight2C = #187; 
LowerRight2C = #188; 
Vertical2C = #186; 
Horizontal2C = #205; 


8.7 Eineerste Anwendung 


Als erstes Beispiel sollen zunächst zwei voneinander unabhängige Fenster 
auf dem Bildschirm geöffnet werden, die abwechselnd als aktives 
Ausgabefenster definiert werden können. Zur Umschaltung zwischen den 
Fenstern sollen die Ziffern 1 bzw. 2 dienen. 


uses crt, Window; 


var WP1, WP2 : BaseWndPT; 
I : integer; 
C : char; 
ActiveWnd : integer; 


begin 
ClrScr; 


new( WndSystemP, Make ); 


WP1:= new( WndiPT, Make( 10, 20, 5, 10, ’Fenster 1’ ) ); 
WP2:= new( WndiPT, Make( 30, 40, 5, 10, ’Fenster 2’ ) ); 
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with WP2” do 
begin 
Open; 
DeActivate; 
end; 


WP1”.Open; 
ActiveWnd:= 1; 


repeat; 
C:= Readkey; 


case C of 


'1' 2 if ActiveWnd = 2 then 
begin 
WP2” .DeActivate; 
WP1”.Activate; 
ActiveWnd:= 1; 
end; 

'‚2' : if ActiveWnd = 1 then 
begin 
WP1”.DeActivate; 
WP2”.Activate; 
ActiveWnd:= 2; 
end; 


else write( C ); 
end; (-- case )} 
until C = '%X'; 


if ActiveWwnd = 1 then 
begin 
WP1”.Close; 
WP2”.DeAllocate; 
end 

else 
begin 
WP1”.DeAllocate; 
WP2”.Close; 
end; 


dispose( WP1, Kill ); 
dispose( WP2, Kill ); 


dispose( WndSystemPp, Kill ); 


end. 


In diesem Programm werden zwei Instanzen des Objekts wndır erzeugt. Die 
Zeiger wpı und wp2 zeigen auf diese Instanzen. Beachten Sie bitte, daß wpı und 
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wp2 zwar vom Typ Basewndt sind, aber Instanzen von wndıT aufnehmen. wp2 
wird nach dem Öffnen zunächst wieder deaktiviert, während uwrı aktiv bleibt. 
Dadurch wird wrı zum aktuellen Ausgabefenster. Eingegebene Zeichen 
(außer den Ziffern 1 und 2 ) werden in dieses Fenster geschrieben. Gibt man 
die Ziffer 2 ein, wird wpı durch den Aufruf von Deactivate deaktiviert, das 
Fenster bleibt jedoch auf dem Bildschirm sichtbar. wr2 ist nun das aktuelle 
Ausgabefenster. Da DeActivate die augenblickliche Cursorposition vor dem 
Verlassen von Fenster 1 abgespeichert hat, kann beim Zurückschalten auf 
Fenster 1 mit der Methode activate der Cursor wieder an die richtige Stelle 
positioniert werden. 


Beachten Sie, daß die beiden Fenster keine Verbindung zueinander haben. In 
den meisten der bekannten Fenstersysteme wird beim Öffnen eines neuen 
Fensters die Zeigerposition gespeichert, um den Zeiger nach dem Schließen 
des Fensters wieder an diese Stelle positionieren zu können. Dadurch wird es 
unmöglich, ein anderes als das gerade aktuelle Fenster zu manipulieren. So 
ist es z.B. im allgemeinen nicht möglich, Fenster in beliebiger Reihenfolge 
zu schließen. Vielmehr müssen die Fenster in der umgekehrten Reihenfolge 
des Offnens wieder geschlossen werden. 


In dem hier vorgestellten Fenstersystem bestehen solche Beschränkungen 
nicht. Auch wenn wp2 nach wpı geöffnet wurde, kann wpı geschlossen werden, 
während wp2 noch aktiv ist. Außerdem können z.B. beide Fenster deaktiviert 
werden, aber auf dem Bildschirm sichtbar bleiben. Fehlermeldungen können 
so in einen Bildschirmbereich außerhalb der Fenster plaziert werden. Im fol- 
genden Beispiel bewirken die Ziffern 3 bzw. 4 das Schließen bzw. Öffnen 
des Fensters 1, unabhängig davon, wieviele andere Fenster noch vorhanden 
sind. 
uses crt, Window; 
var WP1, WP2 : BaseWndPT; 

I : integer; 

C : char; 

ActiveWnd : integer; 


begin 
ClrScr; 


new( WndSystemP, Make ); 


wp1: 
WP2: 


new( WndiPT, Make( 10, 20, 5, 10, ’Fenster 1’ ) ); 
new( WndiPT, Make( 30, 40, 5, 10, 'Fenster 2’ ) ); 


with WP2” do 
begin 
Open; 
DeActivate; 
end; 
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WP1” „Open; 
ActiveWnd:= 1; 


repeat; 
C:= Readkey; 


case C of 


‚1! 2 if ActiveWnd = 2 then 
begin 
WP2”.DeActivate; 
WP1”.Activate; 
ActiveWnd:= 1; 
end; 

ı2' : if ActiveWnd = 1 then 
begin 
WP1”.DeActivate; 
WP2” .Activate; 
ActiveWnd:= 2; 
end; 


13' 2 WP1”.DeAllocate; 


I&! : begin 
WP2” .DeActivate; 
WP1”.Open; 
ActiveWnd:= 1; 
end; 


else write( C ); 
end; {-- case } 
until C = 'X’; 


if ActiveWnd = 1 then 
begin 
WP1”.Close; 
WP2”.DeAllocate; 


begin 
WP1”.DeAllocate; 
WP2“.Close; 

end; 


dispose( WP1, Kill ); 
dispose( WP2, Kill ); 


dispose( WndSystemP, Kill ); 


end. 


Das Programm kann leicht zu einem Fehler führen, z.B. dann, wenn wp1 
aktiv ist und dann versucht wird, durch Eingabe der Ziffer 3 das Fenster 1 zu 
schließen. Die Fehlermeldung Falscher status wird auf dem Bildschirm aus- 
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gegeben, das Programm läuft jedoch weiter. Der Fehler könnte leicht durch 
entsprechende Programmierung vermieden werden, hier ist er jedoch beab- 
sichtigt. 


8.3 Erweiterte Fehlerprüfung 


In den beiden vorigen Beispielen ist die Erzeugung einer Instanz des Objekts 
Wndsystem erforderlich, obwohl vom Anwenderprogramm keine Methode die- 
ses Objekts verwendet wird. In der Unit window selber werden jedoch die 
Methoden wnderror und voıt aufgerufen. Eine der Aufgaben von wndsystent ist 
es, dem Nutzer die Redefinition dieser beiden Methoden zu ermöglichen. Die 
Instanzierung von wndsystemt kann deshalb nicht in window selber geschehen 
(z.B. im Initialisierungsteil), sondern muß vom Anwenderprogramm durch- 
geführt werden. 


Wir wollen die vordefinierte Fehlerbehandlung so abändern, daß vor Aufruf 
jeder Routine geprüft wird, ob wndok den Wert TRUE hat. Da wndok durch die 
Routinen der Unit nach einem Fehler auf FALSE gesetzt wird, kann so er- 
reicht werden, daß Routinen des Fenstersystems erst dann wieder aufgerufen 
werden können, wenn der Fehler vom Nutzer behandelt und wndok wieder auf 
TRUE gesetzt wurde. Die Methode vorirst wird von jeder Fensterroutine als 
erste Anweisung aufgerufen und eignet sich deshalb zur Implementierung der 
Abfrage. 


Um die neue Funktionalität zu implementieren, muß borirst redefiniert wer- 
den. Dazu ist eine Ableitung von wndsystemt erforderlich. Im folgenden Pro- 
gramm ist MyWndsystem dieses abgeleitete Objekt. 


uses crt, Window; 


type MyWndSystemT = object( WndSystemT ) 
procedure DoFirst; virtual; 
end; {-- MyWndSystemT } 
MyWndSystemPT = *MyWndSystemT; 


procedure MyWndSystemT.DoFirst; 
begin 
WndSystemT.DoFirst; 


if not WndOK then 
begin 
writeln( 'WndOK ist false - Programm abgebrochen’ ); 
halt( 1); 
end; 
end; (-- DoFirst } 
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var WP1, WP2 : BaseWndPT; 
I : integer; 
C : char; 
ActiveWnd : integer; 


begin 
ClrScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 


WP1:= new( WndiPT, Make( 10, 20, 5, 10, ’Fenster 1’ ) ); 
WP2:= new( WndiPT, Make( 30, 40, 5, 10, ’Fenster 2' ) ); 


with WP2” do 
begin 
Open; 
DeActivate; 
end; 


WP1*.Open; 
ActivewWnd:= 1; 


repeat; 
C:= Readkey; 
case C of 


'1' 2 if ActiveWnd = 2 then 


begin 
WP2” .DeActivate; 
WP1”.Activate; 
ActiveWnd:= 1; 
end; 

ı2' : if ActiveWnd = 1 then 
begin 
WP1”.DeActivate; 
WP2” .Activate; 
ActiveWnd:= 2; 
end; 


'3' 2 WP1”.DeAllocate; 


I&L! » begin 
WP2” .DeActivate; 
WP1”“.Open; 
ActiveWnd:= 1; 
end; 


else write( C ); 
end; {-- case } 


until C = 'X'; 
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if ActiveWnd = 1 then 
begin 
WP1”*.Close; 
WP2”.DeAllocate; 


begin 
WP1”.DeAllocate; 
WP2”.Close; 

end; 


dispose( WP1, Kill ); 
dispose( WP2, Kill ); 


dispose( WndSystemP, Kill ); 


end. 


Nun bricht das Programm nach Ausgabe einer Fehlermeldung beim nächsten 
Aufruf einer Fensterprozedur mit dem Text wndoK ist false - Programm abgebro- 
chen ab. Die im Anwenderprogramm definierte Methode borirst wird von al- 
len Routinen des Fenstersystems aufgerufen. Es ist guter Stil, im neuen po- 
First zuerst das geerbte Dorirst aufzurufen, selbst wenn bekannt ist, daß dort 
keine Anweisungen ausgeführt werden. Der Entwickler des Fenstersystems 
könnte in einer späteren Version in WndsystemT.DoFirst Code unterbringen. 


Beachten Sie bitte, daß zur Erzeugung einer Instanz von MyWndsystem nicht 
mehr newc Wndsystemp, Make ) geschrieben werden kann, denn durch diese 
Anweisung würde weiterhin eine Instanz von wndsystemt erzeugt. Andererseits 
kann zwar eine Variable vom Typ Mywndsystempt deklariert werden, aber die 
Routinen in Window verwenden die Variable wndsystemp. Die neue Syntax 
von new löst dieses Problem: Sie gestattet die Erzeugung einer Instanz vom 
Typ Myundsystemt, auch wenn die aufnehmende Zeigervariable einen anderen 
Basistyp hat. 


8.9 Eine eigene Fehlerroutine 


Falls nicht beabsichtigt ist, die Variable wndok nach jedem Aufruf einer Fen- 
sterprozedur abzufragen, sollte das Programm bereits beim Auftreten eines 
Fehlers und nicht erst beim nächsten Aufruf einer Fensterprozedur abgebro- 
chen werden. Dazu wird die Fehlerbehandlungsroutine wnderror redefiniert. 
Analog zur Redefinition von Dorirst im letzten Abschnitt ruft das neue 
WndError zuerst die geerbte Methode auf, bevor zusätzliche Schritte ausgeführt 
werden. In unserem Fall reicht es aus, als zusätzlichen Verarbeitungsschritt 
eine Halt-Anweisung einzufügen. 
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uses crt, Window; 


type MyWndSystemT = object( WndSystenT ) 
procedure WndError( ErrorCode : byte ); virtual; 
end; {-- MyWndSystemT } 


MyWndSystemPT = *MyWndSystenT; 
procedure MyWndSystemT.WndError( ErrorCode : byte ); 
begin 
WndSystemT .WndError( ErrorCode ); 
halt( 1 ); 


end; {-- WndError } 


var WP1, WP2 : BaseWndPT; 
I : integer; 
C : char; 
ActiveWnd : integer; 


begin 
ClrScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 


WP1: 
WP2: 


new( WndiPT, Make( 10, 20, 5, 10, ’Fenster 1’ ) ); 
new( WndiPT, Make( 30, 40, 5, 10, 'Fenster 2’ ) ); 


with WP2” do 
begin 
Open; 
DeActivate; 
end; 


WP1”.Open; 
ActiveWnd:= 1; 


repeat; 
C:= ReadKey; 


case C of 


'1' 2 if ActiveWnd = 2 then 
begin 
WP2” .DeActivate; 
WP1”.Activate; 
ActiveWnd:= 1; 


end; 

'2' : if ActiveWnd = 1 then 
begin 
WP1”.DeActivate; 
WP2” .Activate; 
ActiveWnd:= 2; 
end; 


'3' . WP1”.DeAllocate; 
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'4'! . begin 
WP2” .DeActivate; 
WP1”.Open; 
ActiveWnd:= 1; 
end; 
else write( C ); 
end; (-- case } 
until C = 'X'; 
if ActiveWnd = 1 then 
begin 
WP1”.Close; 
WP2”.DeAllocate; 


begin 
WP1”.DeAllocate; 
WP2”.Close; 

end; 


dispose( WP1, Kill ); 
dispose( WP2, Kill ); 


dispose( WndSystemP, Kill ); 


end. 


Die zusätzliche Funktionalität der neuen Fehlerbehandlungsroutine ist nicht 
auf die Ausführung der Hatt-Anweisung beschränkt. Denkbar wäre z.B. die 
zusätzliche Ausgabe der Fehlermeldung in eine Protokolldatei, evtl. ergänzt 
durch einen Abzug des augenblicklichen Bildschirminhalts. Später kann dann 
die Protokolldatei - bei professionellen Programmen z.B. im Rahmen der 
Programmwartung - analysiert werden. 


8.10 Eigene Fensterobjekte 


Ein Anspruch, den wir an das neue Fenstersystem gestellt haben, ist die 
Möglichkeit zur Integration von Fenstern, die erst im Anwenderprogramm 
definiert werden. Wir wollen als Beispiel das aus Kapitel 6 bekannte Fenster- 
objekt wna3t betrachten. Damit wnd3T richtig integriert werden kann, ist die 
Aufteilung der Funktionalität auf die Methoden Atllocate, Activate, DeAllocate 
und Deactivate erforderlich. Das folgende Programmsegment zeigt Definition 
und Implementierung eines Fensterobjekts mit Scrollbars. 
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C-- Scrollbars --) 


const ScrollBarC 


(-- Objektdefinition --) 


type Wnd3T 


WHorizontalScroll, 
WVerticalScroll : Integer; 


constructor Make( XMin, XMax, YMin, YMax : integer; 


procedure Activate; virtual; 


procedure SetHorizontalScroll( Percent : 


procedure SetVerticalScroll( Percent 
end; {-- Wnd3T } 


Wnd3PT = “yund3T; 


{(-- Objektimplementierung --} 


constructor Wnd3T.Make( XMin, XMax, YMin, YMax : 


begin WndSystemP”“.DoFirst; 

Wndi1T.Make( XMin, XMax, YMin, YMax, Name ); 
WHorizontalScroll:= 0; 

WVerticalScroll:= 0; 

end; {-- Make } 


procedure Wnd3T.Activate; 

begin WndSystemP”“.DoFirst; 
Wndi1T.Activate; 

SetHorizontalScroll( WHorizontalScroll ); 
SetVerticalScroll( WVerticalScroll ); 
end; {-- Activate } 


procedure Wnd3T.SetHorizontalScroll( Percent : 


var I : Integer; 
Size : integer; 
var SaveXCur, SaveYCur : integer; 


begin WndSystemP“.DoFirst; 


(-- RangeCheck Parameter --)} 

if ( Percent < O0 ) or ( Percent > 100 ) then 
begin 
WndSystemP”“.WndError( WndWrongScroll ); 
exit; 
end; 


object( Wnd1T ) 


integer ) 


#176; (-- graues Viereck } 


integer ) 
integer ); 


integer; Name : 


‘ 


: WNameT ); 


WNameT ); 
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WHorizontalScroll:= Percent; 


SaveXCur:= WhereX; SaveYCur:= WhereY; 
crt.Window( WXmin, WYMin, WXMax, WYMax ); 
Size:= pred( WXMax - WXMin ); {-- Anzahl Zeichen in ScrollArea } 


gotoXY( 2, succ( WYMax-WYMin ) ); 
for Il:= 1 to Size do 
write( ScrollBarC ); 


gotoXY( trunc( Percent/100*pred( Size ) )+2, succ( WYMax - WYMin ) ); 
HighVideo; 

write( ScrollBarC ); 

LowVideo; 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 


gotoXY( SaveXCur, SaveYCur ); 
end; {-- SetHorizontalScroll } 


procedure Wnd3T.SetVerticalScroll( Percent : integer ); 


var I : integer; 
Size : integer; 
var SaveXCur, SaveYCur : integer; 


begin WndSystemP“.DoFirst; 


{-- RangeCheck Parameter --} 

if C Percent < DO ) or ( Percent > 100 ) then 
begin 
WndSystemP“.WndError( WndWrongScroll ); 
exit; 
end; 


WVerticalScroll:= Percent; 


SaveXCur:= WhereX; SaveYCur:= WhereY\; 
cert.Window( WXmin, WYMin, WXMax, WYMax ); 
Size:= pred( WYMax - WYMin ); {-- Anzahl Zeichen in ScrollArea ) 


for I:= 1 to Size do 
begin 
gotoXY( succ( WXMax-WXMin ), succ( I ) ); 
write( #176 ); 
end; 


gotoXY( succ( WXMax - WXMin ), trunc( Percent/100*pred( Size ) )+2 ); 
HighVideo; 

write( #176 ); 

LowVideo; 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
gotoXY( SaveXCur, SaveYCur ); 
end; {-- SetVerticalScroll } 
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Das Beispiel zeigt, daß die Methoden Allocate, DeActivate und DeAllocate VON 
Wnd1T geerbt werden können. Nur die Methode activate muß redefiniert wer- 
den. In dieser Implementierung sind die Scrollbars nur sichtbar, wenn das 
Fenster aktiv ist. Deaktivierte Fenster werden mit normalem Rahmen darge- 
stellt. Sollen die Scrollbars auch in deaktiviertem Zustand sichtbar bleiben, 
muß der Aufruf von SetHorizontalScroll DZW. SetVerticalScroll iN Allocate und 
DeActivate verlegt werden. 


Im folgenden Beispiel wird wnd3t als zweites Fenster definiert. Zur Um- 
schaltung zwischen beiden Fensters werden die Tasten 1 und 2 verwendet. 


uses crt, Window; 


{$1 W301 3 €-- MyWndSystemT } 
{$I W302 )3 {-- Wnd3T } 


var WP1, WP2 : BaseWndPT; 
I : integer; 
C : char; 
ActiveWnd : integer; 


begin 
ClrScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 


WP1: 
WP2: 


new( Wndi1PT, Make( 10, 20, 5, 10, ’Fenster 1’ ) ); 
new( Wnd3PT, Make( 30, 40, 5, 10, ’Fenster 2' ) ); 


with WP2” do 
begin 
Open; 
DeActivate; 
end; 


WP1”*.Open; 
ActiveWnd:= 1; 


repeat; 
C:= ReadKey; 


case C of 


1! » if ActiveWnd = 2 then 
begin 
WP2” .DeActivate; 
WP1*.Activate; 
ActiveWnd:= 1; 
end; 

ı2' : if ActiveWnd = 1 then 
begin 
WP1”.DeActivate; 
WP2” .Activate; 
ActiveWnd:= 2; 
end; 
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else write( C ); 
end; (-- case } 

until C = 'X'; 

if ActiveWnd = 1 then 
begin 
WP1”.Close; 
WP2”.DeAllocate; 
end 

else 
begin 
WP1”.DeAllocate; 


WP2”.Close; 
end; 


dispose( WP1, Kill ); 
dispose( WP2, Kill ); 


dispose( WndSystemP, Kill ); 


end. 


Die Definition und Implementierung von Mywndsystemt wurde in die Datei 
W301, Definition und Implementierung von wna3t in die Datei W302 ausge- 
lagert. Der einzige Unterschied zu früheren Beispielen liegt darin, daß in der 
New-Anweisung für das zweite Fenster nun wna3pt anstelle von wnd1Ppt steht. 
Einfacher kann die Integration eigener Elemente kaum noch sein! 


8.11 Die Verwendung des Kellerspeichers 


WndSystemt exportiert zwei Methoden, die die Verwaltung übereinanderliegen- 
der Fenster übernehmen können. Bei übereinanderliegenden Fenstern muß 
darauf geachtet werden, daß die Fenster in umgekehrter Reihenfolge des Öff- 
nens wieder geschlossen werden. Diese Reihenfolge wird automatisch einge- 
halten, wenn die Methoden openwnd und Closewnd verwendet werden. Folgen- 
des Beispielprogramm zeigt eine Anwendung dieser Methoden: 
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uses crt, Window; 
{$I W301 )3 €-- MyWndSystemT )} 
var C : char; 


begin 
ClrScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 
WndSystemP* .OpenWnd( new WndiPT, Make( 10, 20, 5, 10, ’Fenster 1' ) ) ); 
WndSystemP“*.OpenWnd( new( WndiPT, Make( 30, 40, 5, 10, ’Fenster 2’) ) ) 


repeat 
C:= Readkey; 
case C of 


‚1! 2 if WndSystemP“.CloseWnd then; 


else write( C ); 
end; {-- case } 


until C = '’X'; 


repeat 
until not WndSystemP”.CloseWnd; 


dispose( WndSystemP, Kill ); 


end. 


Da die Verwaltung der Fenster nun vollständig von wndsystemt übernommen 
wird, sind im Anwendungsprogramm keine Variablen für die Instanzen mehr 
erforderlich. Ein Anwendungsprogramm kann so eine variable Anzahl 
Fenster verwalten, ohne daß diese Zahl zur Übersetzungszeit bekannt sein 
müßte. Ebenso kann die Variable Activewnd entfallen, da automatisch das 
"obenliegende" (d.h. das zuletzt geöffnete Fenster) aktiviert und alle anderen 
Fenster deaktiviert sind. Als zusätzliche Leistung hält wndsystemt einen Zeiger 
auf das gerade aktive Fenster bereit. Dieser Zeiger wird z.B von 
Repositionwnd verwendet, um das aktuelle Fenster auf dem Bildschirm zu 
verschieben. Im folgenden Programm kann durch Eingabe von 1 bzw. 2 ein 
Fenster geöffnet bzw. geschlossen werden. Das jeweils oberste Fenster kann 
durch die Pfeiltasten in der entsprechenden Richtung um eine 
Bildschirmposition versetzt werden. 
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uses crt, Window; 
{$1 W301 > €{-- MyWndSystenT } 
var C : char; 


begin 
CirScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 
repeat 
C:= Readkey; 
case C of 


‚1' : begin 
with WndSystemP”, ActiveWP”“ do 
if ActiveWP = nil then 
OpenWnd( new( WndiPT, Make( 10, 20, 5, 10, ''))) 
else 
OpenWnd( new( WndiPT, 
Make( WXMin + 3, WXMax + 3, WYMin + 2, WYMax + 2, '')) ); 
ClrScr; 
end; 


‚2! x» if WndSystemP”“.CloseWnd then; 
#0 : begin 


C:= Readkey; 
with WndSystemP”“ do 


case C of 
#75 : RepositionWnd( -1, 0 ); C-- links ) 
#72 : RePositionWnd( 0, -1 ); {-- oben } 
#77 : RepositionWnd( 1, 0 ); {-- rechts } 
#80 : RepositionWnd( 0, 1 ); {-- unten } 
end; {-- case } 

end; {-- #0 } 


else write( C ); 
end; {-- case ) 


until C = 'X'; 


repeat 
until not WndSystemP“.CloseWnd; 


dispose( WndSystemP, Kill ); 


end. 
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Dieses Programm zeigt, wie man mit einfachen Mitteln bereits eindrucks- 
volle Effekte auf dem Bildschirm hervorbringen kann. Für eine sinnvolle 
Anwendung müßten allerdings noch einige Probleme beseitigt werden. So 
werden beispielsweise einige Fehler nicht abgefangen. Verschiebt man z.B. 
ein Fenster bis an den Rand des Bildschirms, wird diese Situation nicht er- 
kannt und führt zum Absturz des Programms. Auf die Implementierung zu- 
sätzlicher Fehlerprüfung zur Vermeidung dieses und ähnlicher Fehler wurde 
verzichtet, um den Quellcode nicht zu unübersichtlich zu machen. 


8.12 Ein Beispiel mit Exploding Windows 


Im folgenden Programm werden nicht Fenster vom Typ wndıt sondern vom 
Typ wndat erzeugt. Der Konstruktor wnd2T.Make hat zwei Parameter mehr, die 
den Startpunkt für den Offnungsprozess angeben. Diese beiden Parameter 
müssen in absoluten Bildschirmkoordinaten angegeben werden. Um die Öff- 
nung des neuen Fensters von der aktuellen Zeigerposition aus zu beginnen, 
ist daher eine Umrechnung der Fensterkoordinaten auf Bildschirmkoordina- 
ten durchzuführen. Die Prozeduren wherex und wherey liefern die aktuelle Zei- 
gerposition bezogen auf das aktuelle Fenster. Zur Umrechnung auf Bild- 
schirmkoordinaten müssen nur die Offsets der Fensterkoordinaten addiert 
werden. 


uses crt, Window; 
{$I W301 > €-- MyWndSystemT } 
var C : char; 


begin 
CirScr; 


WndSystemP:= new( MyWndSystemPT, Make ); 
repeat 
C:= Readkey; 
case C of 


’1' 2 begin 
with WndSystemP”, ActiveWP“ do 
if ActiveWP = nil then 
OpenWnd( new Wnd2PT, Make( 10, 20, 5, 10, '', 2,2))) 
else 
OpenwWnd( new( Wnd2PT, 
Make( WXMin + 3, WXMax + 3, WYMin + 2, WYMax + 2, '', 
Wherex + pred( WXMin ), WhereY + pred( WYMin ) ) ) ); 
ClrScr; 
end; 
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2’ 2 if WndSystemP”.ClosewWnd then; 


#0 : begin 
C:= Readkey; 
with WndSystemP” do 
case C of 


#75 : RepositionWnd( -1, 0 ); (-- links } 
#72 : RePOsitionWnd( 0, -1 ); {-- oben )} 
#77 : RepositionWnd( 1, 0 ); (-- rechts } 
#80 : RepositionWnd( 0, 1); {-- unten } 
end; {-- case } 

end; {-- #0 }) 


else write( C ); 
end; {-- case } 


until C = 'X'; 


repeat 
until not WndSystemP”“ .CloseWnd; 


dispose( WndSystemP, Kill ); 


end. 


Die Berechnung der absoluten Bildschirmkoordinaten wird im folgenden 
Programm direkt beim Aufruf von openwnd durchgeführt. Wenn Transforma- 
tionen zwischen Fenster- und Bildschirmkoordinaten öfter gebraucht werden, 
sollten die Berechnungen in eigens dafür vorgesehene Methoden verlegt wer- 
den. 


8.13 Zusammenfassung 


Dieses Kapitel zeigt am Beispiel eines Fenstersystems die wesentlichen 
Techniken professioneller objektorientierter Programmierung auf. Das Fen- 
stersystem ist bereits vom Entwurf her so ausgelegt, daß die Vorteile objekt- 
orientierter Programmierung zur Geltung kommen können. Die zentrale Ei- 
genschaft, von der immer wieder Gebrauch gemacht wird, ist die Möglich- 
keit zur Redefinition virtueller Methoden in Objekthierarchien. In den Bei- 
spielprogrammen wird die Redefinition virtueller Methoden verwendet, um 
spezielle Fehlerbehandlungen sowie zusätzliche Fensterobjekte zu definieren. 
Da das Fenstersystem so einfach zu erweitern ist, muß der Entwickler nicht 
mehr alle Anwendungsfälle voraussehen, sondern kann spezielle Anwendun- 
gen dem Anwendungsprogrammierer überlassen. Die Struktur von allge- 
meinverwendbaren Units kann auf diese Weise einfacher und damit war- 
tungsfreundlicher gehalten werden. Die Qualität von Toolboxen, die objekt- 
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orientiert programmiert sind, wird nicht mehr an der Anzahl der bereitge- 
‚stellten Funktionen gemessen, sondern an den Möglichkeiten, mit denen der 
Anwender die Funktionalität nach seinen Wünschen beeinflussen kann. Die 
Hook-Technik, hier dargestellt an der Prozedur oorirst, ist ein speziell für 
die objektorientierte Programmierung geeignetes Mittel, um diese Flexibilität 
zu gewährleisten. Es reicht eben nicht aus, in ein fertiges System einige Ob- 
jekte einzufügen, um eine "Objektorientierte Library" zu erhalten. 
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Anhang: Listings 


Im Anhang sind noch einmal alle wesentlichen Units vollständig aufgelistet. 
In dieser Form können sie auch beim Autor auf Diskette erhalten werden. 


A.1 Unit General 


A.1.1 Datei General 


unit General; 

interface 

uses crt, dos; 

£-- Bildschirmorientierte Routinen ----------------------- G110 ----} 
function GetScreenBase : word; 

{-- Tastaturorientierte Routinen ------------ 7777 G120 ----) 
function Keypressed2 : boolean; 

{-- Logikroutinen ---------------- He meoeeeeen G130 ----} 
function Sign( A : integer ) : integer; 

implementation 

{$1 G110 3 C-- Bildschirmorientierte Routinen } 

{$1 G120 } (-- Tastaturorientierte Routinen ) 


{$1 G130 } {-- Logikorientierte Routinen B 


end. 
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A.1.2 Datei G110 


{-- Bildschirmorientierte Routinen --) {-- G110 } 


function GetScreenBase : word; 


{ 
liefert die Segmentadresse des Bildschirmspeichers 
:; 
ver R : Registers; 
begin 


Intrt $11, R ); {-- BIOS EquipmentList } 

if R.AX and $30 = $30 then (-- Monochromadapter } 
GetScreenBase:= $BO00 

else 
GetScreenBase:= $B800; 

end; {-- GetScreenBase } 


A.1.3 Datei G120 


{-- Tastaturorientierte Routinen } {-- G120 } 
function Keypressed2 : boolean; 
var C : char; 


begin 
if Keypressed then 
begin 
KeyPressed2:= true; 
C:= Readkey; 
end 
else 
KeyPressed2:= false; 
end; (-- KeyPressed2 } 
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A.1.4 Datei G130 


function Sign( A : integer ) : integer; 


{ 
liefert das erweiterte Vorzeichen von A 
A<O -1 
A=0 0 
A>O 1 
> 
begin 
if A< 0 then 
Sign:= -1 
else 
ifA>0 then 
Sign:= 1 
else 
Sign:= 0; 


end; {-- Sign ) 


A.2 Kellerspeicher aus Kapitel 5 


A.2.1 Datei StackU 


unit StackU; 
{ 
StackT definiert einen Stack mit 10 Elementen. 
Push legt ein Element ab, liefert true wenn noch Platz 
fuer ein weiteres Element ist. 
Pop liefert eine Element, nil wenn Stack leer ist. 


> 
interface 
{-- Urtyp eines Stackelements -------------------- oem > 


type StackElmT 
end; 


object {-- Kap5l18 } 


StackElmPT *StackElnT; 
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{-- Der Stack selber ---------------- oe o-00nn s110 --------- } 
const MaxEntriesC = 10; 
type StackT = object 
Buffer : array[ 1..MaxEntriesCc ] of StackElmPT; 
Index : integer; 


procedure Make; 
procedure Kill; 


function Push( EP : StackElmPT ) : boolean; 
function Pop : StackElmPT; 
end; (-- StackT } 


implementation 


($1 S110 3 C-- Make, Kill } 
($1 S120 3 (-- Push, Pop } 


end. 


A.2.2 Datei S110 


{--- Implementierung StackT Make, Kill ----) 


procedure StackT.Make; 
begin 

Index:= 1; 

end; {-- Make ) 


procedure StackT.Kill; 
begin 
end; {-- Kill }) 
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A.2.3 Datei S120 


{--- Implementierung StackT Push, Pop --} 


function StackT.Push( EP : StackElmPT ) : boolean; 
begin 


if Index = MaxEntriesC then (-- Speicher voll. EP nicht eintragen } 
begin 
Push:= false; 
exit; 
end; 


Buffer[ Index ] := EP; 
inc( Index ); 
Push:= true; 


end; {-- Push } 


function StackT.Pop : StackElmPT; 
begin 


if Index = 1 then {-- Speicher leer. nil zurueckliefern } 
begin 
Pop:= nil; 
exit; 
end; 


dec( Index ); 
Pop:= Buffer[ Index ]; 


end; {-- Pop } 
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A.3 Fenstersystem aus Kapitel 6 


A.3.1 Datei Window 


unit window; 
interface 
uses crt, general, StackU; 


{$I W101.dcl 3 €-- Im InterfaceTeil gebrauchte Deklarationen } 
{$I W102.del > C-- Fehlervariablen und Konstanten > 


E----------- Generelle Prozeduren ------------------------ 770-0 00007 } 


function WndCheck( ErrorCode : byte ) : boolean; 
procedure msg ( ErrorCode : byte ); 


E----- 00-00 PreBaseWndT ---------------------- ee eeeeeeeeeeeen ) 
type PreBaseWndT = object( StackElmT ) 
ObjectType : ( BaseWnd, Wndi1, Wnd2, Wnd3 ); 
end; {-- PreBaseWndT } 
type PreBaseWndPT = “PreBaseWndT; 
{mn BaseWndT ------------- oo een } 
type BaseWndT = object( PreBaseWndT ) 
WXMin, WXMax, 
WYMin, WYMax : integer; 
XCur, YCur : integer; {-- Cursorposition vor Oeffnen } 
Status : WndStatusT; 
Savep : LongArrayPT; (-- gesicherter Bildschirmbereich } 


ColCount, LineCount : integer; 
Amount : integer; 


procedure Make; 
procedure Kill; 


procedure Open( XMin, XMax, YMin, YMax : integer ); 
procedure Close; 


end; {-- BaseWndT } 


type BaseWndPT = "BaseWndT; 
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type WndiT = object( BaseWndT ) 
WName : WNameT; 
procedure Make; 
procedure Open( XMin, XMax, YMin, YMax 
procedure SetStandard; 
procedure SetAlternate; 


end; {-- Wndi1T > 


type WndiPT = *Wnd1T; 
[----------- WNd2T ---- HH nennen 
type Wnd2T = object( WndiT ) 


WXStart, WYStart : Integer; 


procedure Make; 

procedure Open( XMin, XMax, YMin, YMax 
XStart, YStart : integer ); 

procedure Close; 


end; {-- Wnd2T } 


type Wnd2PT = *Wnd2T; 
(----- nn. WNd3T  _------------- - --S---0R-07 menennnn- 
type Wnd3T = object( Wnd2T ) 


WHorizontalScroll, 
WVerticalScroll : integer; 
procedure Make; 

procedure SetHorizontalScroll( Percent 
procedure SetVerticalScroll( Percent : integer ); 
end; (-- Wnd3T } 


type Wnd3PT 


I 

> 
x 
B. 
N 
kan 


[He WndStackT -------------------------44Ha Henne 


type WndStackT 


object( StackT ) 
ActiveWP : PreBaseWndPT; 
procedure Make; 


procedure OpenBaseWnd( XMin, XMax, YMin, YMax 


procedure OpenWndi( XMin, XMax, YMin, YMax 
Name : WNameT ); 


: integer; Name : 


: integer; Name : 


: integer ); 


: integer; 


===. =... 2.2... 0... ) 
WNameT ); 

„=... 2.1... 2.0... ) 
WNameT; 

.= 2.222.220. 0.0. ) 

„nm... 22.200. .0.. ) 


: integer ); 
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procedure OpenWnd2( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


procedure OpenWnd3( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


procedure CloseWnd; 

end; {-- WndStackT } 
type WndStackPT = “WndStackT; 
implementation 


{$1 W111.del > (-- ScreenT } 
{$1 W112.del > (-- Konstanten fuer Rahmen und Scrollbars } 
B 


{$1 W120 (-- Generelle Prozeduren } 
{$1 W100 > {-- Methoden BaseWndT } 
{$1 W101 > {-- Methoden Wnd1T B 
{$1 W102 > (-- Methoden Wnd2T B 
{$1 W103 > {-- Methoden Wnd3T B 
{$1 W110 > (-- Methoden WndStackT } 
begin 


ScreenP:= ptr( GetScreenBase, 0 ); 

(-- Standardeinstellung: Alle Fehler bewirken Meldung und Abbruch --) 
MsgCodeSet := [ 0..255 ]; 

HaltCodeSet:= [ 0..255 ]; 


end. 


A.3.2 Datei W101.del 


{-- Bezeichnet den Zustand eines Fensters. Sinnvoll fuer 
erweiterte Fehlerpruefungen --} 


type WndStatusT 


= ( closed, {-- kein Speicher zugewiesen ) 
active ); {-- Fenster offen } 


{-- LongArrayT erlaubt die Interpretation eines Speicherbereiches als 
Folge von Einzelzeichen --) 


array[ 1..MaxInt ] of char; 
*LongArrayT; 


type LongArrayT 
LongArrayPT 
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{-- WNameT aus Speicherplatzgruenden eingefuehrt --} 


type WNameT string[ 20 ]; 


type ErrorCodeSetT set of byte; 


var MsgCodeSet, HaltCodeSet : ErrorCodeSetT; 


A.3.3 Datei W102.decl 


var WndOK : boolean; {-- true : kein Fehler } 
WndError : integer; {-- Fehlernummer falls WndOK = false } 


const WndWrongParam 
WndTooSmall 
WndNoMem 
WndWrongStat 
WndWrongStart 
WndWrongScroll 


ng wg Se “oe 


u} 


WndStackEmpty 
WndStackrFull 


u na 
nn: “oe 


ne) ON euruno 


u} 


WndNotOK 


A.3.4 Datei Wi11.del 


(-- Interpretation eines Hauptspeicherbereiches als Bildschirmspeicher } 


80; {-- Spalten pro Zeile } 
25; {-- Bildschirmzeilen } 


const ScrColumnsC 
ScrLinesC 
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type ScrCharT 
Ch 
Attr 
end; {-- ScrCharT } 


type ScrLineT = 


type ScreenPT 
ScreenT 


record 
char; (-- Das eigentliche Zeichen } 
byte; (-- Attribut des Zeichens } 


array[ 1..ScrColumnsCc ] of ScrCharT; 


*ScreenT; 
array[ 1..ScrLinesC ] of ScrLineT; 


{-- ScreenP zeigt auf Hardwarebildschirm. Wird im Initialisierungsteil 
von Window initialisiert --} 


var ScreenPp 


: ScreenPT; 


A.3.5 Datei W112.del 


{-- Konstanten fuer Rahmen und 
{-- Einfacher Rahmen --) 


const UpperLeftiC 
LowerLeftiC 
UpperRightiC 
LowerRight1iC 


VerticaliC 
HorizontalIC 


{-- Doppelter Rahmen --) 


const UpperLeft2C 
LowerLeft2C 
UpperRight2C 
LowerRight2C 


Vertical2C 
Horizontal2C 


(-- Scrollbars --)} 


const ScrollBarC = 


Scrollbars etc --} 


#176; {-- graues Viereck } 
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A.3.6 Datei W120 


procedure msg( ErrorCode : byte ); 
begin 


case ErrorCode of 


WndWrongParam : writeln( ’Falsche Parameter’ ); 
WndTooSmall : writeln( ’Fenster zu klein’ ); 
WndNoMem : writeln( ’Kein Speicher mehr’ ); 
WndWrongStat : writeln( ’Falscher Status’ ); 
WndWrongStart : writeln( ’Falsche Startwerte’ ); 
WndWrongScroll : writeln( ’Falsche Scrollbars’ ); 
WndStackEmpty : writeln( ’Keine offenen Fenster mehr’ ); 
WndStackFull : writeln( ’Kein Platz mehr auf Stack’ ); 
WndNotOK : writeln( ’WndOK ist noch falsch’ ); 


end; {-- case )} 
end; {-- msg } 


function WndCheck( ErrorCode : byte ) : boolean; 


begin 
WndError:= ErrorCode; 


if ErrorCode in MsgCodeSet then 
begin 
msg( ErrorCode ); 
WndOK:= true; 
end 
else 
WndOK:= false; 


if ErrorCode in HaltCodeSet then 
halt( 1 ); 


WndCheck:= not WndOK; 
end; {-- WndCheck } 
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A.3.7 Datei W100 


procedure BaseWndT .Make; 
begin 

Status:= closed; 
WndOK:= true; 
ObjectType:= BaseWnd; 
end; {-- Make ) 


procedure BaseWndT .Kill; 
begin 


{-- Statuspruefung --} 
if Status <> Closed then 
if WndCheck( WndWrongStat ) then exit; 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


end; (-- Kill } 
procedure BaseWndT.Open( XMin, XMax, YMin, YMax : integer ); 


var I, J : integer; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


{-- RangeCheck der Parameter --} 

if ( XMin < 1 ) or ( XMax > ScrColumsC ) or 
( YMin < 1 ) or ( YMin > ScrLinesC ) then 
if WndCheck( WndWrongParam ) then exit; 


{-- Fenster muss mindestens 1x1 gross sein --} 
if C XMax - XMin < 2 ) or ( YMax - YMin < 2 ) then 
if WndCheck( WndTooSmall ) then exit; 


{-- Statuspruefung --} 
if Status <> Closed then 
if WndCheck( wndWrongStat ) then exit; 


{-- Feststellen des zu sichernden Bildschirmbereiches --} 
ColCount:= 2*succ( XMax-XMin ); {-- bytes pro Zeile )} 
LineCount:= succ( YMax-YMin ); {-- Anzahl Zeilen } 
Amount:= LineCount * ColCount; 


if MaxAvail < Amount then 
if WndCheck( WndNoMem ) then exit; 


GetMem( SaveP, Amount ); 
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{-- Zeilenweise in SaveP“ ablegen --} 


J:= 1; 
for I:= YMin to YMax do 
begin 


move( ScreenP”[ I, XMin ], SaveP”[ J ], ColCount ); 
J:= J + ColCount; 
end; 


{-- Fensterkoordinaten und Cursorposition --)} 
WXMin:= XMin; WXMax:= XMax; 

WYMin:= YMin; WYMax:= YMax; 

XCur:= WhereX; YCur:= WhereY; 

Status:= active; 


ert.Window( XMin, YMin, XMax, YMax ); 
gotoXY( 1, 1); 


end; (-- Open } 


procedure BaseWndT.Close; 
var I, J : integer; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


{-- Statuspruefung --} 
if Status = Closed then 
if WndCheck( WndWrongStat ) then exit; 


ert.Window(t 1, 1, 80, 25 ); 


{-- Zeilenweise aus SaveP”“ holen --} 
J:= 1; 
for I:= WYMin to WYMax do 
begin 
move( SaveP”[ J ], ScreenP”[ I, WXMin ], ColCount ); 
J:= J + ColCount; 
end; 


FreeMem( SaveP, Amount ); 
gotoXY( XCur, YCur ); 
Status:= closed; 

end; (-- Close } 
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A.3.8 Datei W101 


procedure Wnd2T .Make; 


begin 


Wnd1T.Make; 
ObjectType:= Wnd2; 


end; {-- Make } 


procedure Wnd2T.Open( XMin, XMax, YMin, YMax : integer; Name : 
XStart, YStart : integer ); 


var XMinDelta, XMaxDelta, 
YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 


TempYMin, TempYMax 


var Done 
D 


begin 


if not WndOK then 
if WndCheck( WndNotOK ) then 


: integer; 


: boolean; 
: integer; 


{-- RangeCheck Parameter --) 


if ( XStart < 2 ) or ( YStart < 


if WndCheck( WndWrongStart ) 


WXStart:= XStart; 


WYStart:= 


XMinDelta:= 


YStart; 


Sign( 


XMaxDelta:= Sign( 
YMinDelta:= Sign( 
YMaxDelta:= Sign( 


TempXMin: 
TempXMax: 
TempYMin: 
TempYMax: 


XStart 
XStart 
YStart 
YStart 


XMin 
XMax 
YMin 
YMax 


+ 
+ 
+ 
+ 


XStart 
XStart 
YStart 
YStart 


XMinDelta; 
XMaxDelta; 
YMinDelta; 
YMaxDelta; 


exit; 


2 ) then 
then exit; 


ma wa “we “ae 


WNameT; 
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repeat 
Done:= true; 
D:= 0; 


if TempXMin <> XMin then 
begin 
inc( TempXMin, XMinDelta ); 
incl D, 5); 
Done:= false; 
end; 


if TempXMax <> XMax then 
begin 
inc( TempXMax, XMaxDelta ); 
inc D, 5); 
Done:= false; 
end; 


if TempYMin <> YMin then 
begin 
inc( TempYMin, YMinDbelta ); 
incl D, 5); 
Done:= false; 
end; 


if TempYMax <> YMax then 
begin 
inc( TempYMax, YMaxDelta ); 
inc D, 5); 
Done:= false; 
end; 


Wnd1T.Open( TempXMin, TempXMax, TempYMin, TempYMax, Name ); 
if not WndOK then exit; 


delay( D ); 
if not Done then 
begin 
Wnd1T.Close; 
if not WndOK then exit; 
end; 


until Done; 


end; {-- Open } 
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procedure Wnd2T.Close; 


var XMinDelta, XMaxDelta, 
YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 


TempYMin, TempYMax : integer; 
var Done : boolean; 

D : integer; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


XMinDelta:= Sign( WxStart - WXMin ); 
XMaxDelta:= Sign( WxStart - WXMax ); 
YMinDelta:= Sign( WYStart - WYMin ); 
YMaxDelta:= Sign( WYStart - WYMin ); 


succ( WXMin 


TempXMin: ); 
pred( WXMax ); 
); 
); 


TempXMax: 
TempYMin: 
TempYMax: 


succ( WYMin 
pred( WYMax 


repeat 


Done:= true; 
D:= 0; 


if ( TempXMax = TempXMin ) and ( TempYMax = TempYMin ) then 
begin {-- Verschieben --} 


D:= 20; 

if TempXMin <> WXStart then 
begin 
inc( TempXMin, XMinDelta ); 
inc( TempXMax, XMaxDelta ); 
Done:= false; 
end; 


if TempYMax <> WYstart then 
begin 
inc( TempYMin, YMinDelta 
inc( TempYMax, YMaxDelta ); 
Done:= false; 
end; 


ns 
n. 


end 
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else 
begin {-- Verkleinern } 


if C XMinDelta > O0 ) and ( TempXMin <> WXStart ) then 
begin 
if TempXMax - TempXMin > O then 
inc( TempXMin, XMinDelta ); 
inc D, 5); 
Done:= false; 
end; 


if C XMaxDelta < O0 ) and ( TempXMax <> WXStart ) then 
begin 
if TempXMax - TempXMin > O then 
inc( TempXMax, XMaxDelta ); 
inc( D,5); 
Done:= false; 
end; 


if C YMinDelta > O0 ) and ( TempYMin <> WYStart ) then 
begin 
if TempYMax - TempYMin > O then 
inc( TempYMin, YMinDelta ); 
incl D, 5); 
Done:= false; 
end; 


if C YMaxDelta < O0 ) and ( TempYMax <> WYStart ) then 
begin 
if TempYMax - TempYMin > O then 
inc( TempYMax, YMaxDelta ); 
inct D, 5); 
Done:= false; 
end; 
end; 


Wnd1T.Close; 
if not WndOK then exit; 


if not Done then 
begin 
Wnd1T.Open( TempXMin, TempXMax, TempYMin, TempYMax, WName ); 
if not WndOK then exit; 
delay( D ); 
end; 


until Done; 


end; {-- Close } 
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A.3.9 Datei W103 


procedure Wnd3T.Make; 
begin 

Wnd2T .Make; 
ObjectType:= Wnd3; 
end; {-- Make } 


procedure Wnd3T.SetHorizontalScroll( Percent : integer ); 


var | : integer; 
Size : integer; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


{-- RangeCheck Parameter --)} 
if C Percent < O0 ) or ( Percent > 100 ) then 
if WndCheck( WndWrongScroll ) then exit; 


ert.Window( WXmin, WYMin, WXMax, WYMax ); 
Size:= pred( WXMax - WXMin ); (-- Anzahl Zeichen in ScrollArea ) 


gotoXY( 2, succ( WYMax-WYMin ) ); 
for I:= 1 to Size do 
write( ScrollBarC ); 


gotoXY( trunc( Percent/100*pred( Size ) )+2, succ( WYMax - WYMin ) ); 
HighVideo; 

write( ScrollBartC ); 

LowVideo; 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
end; {-- SetHorizontalScroll } 


procedure Wnd3T.SetVerticalScroll( Percent : integer ); 


var I : integer; 
Size : integer; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


{-- RangeCheck Parameter --)} 
if ( Percent < O0 ) or ( Percent > 100 ) then 
if WndCheck( WndWrongScroll ) then exit; 


crt.Window( WXmin, WYMin, WXMax, WYMax ); 
Size:= pred( WYMax - WYMin ); {-- Anzahl Zeichen in ScrollArea } 
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for I:= 1 to Size do 
begin 
gotoXY( succ( WXMax-WXMin ), succ( I ) ); 
write( #176 ); 
end; 


gotoXY( succ( WXMax - WXMin ), trunc( Percent/100*pred( Size ) )+2 ); 
HighVideo; 

write( #176 ); 

LowVideo; 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
end; (-- SetVerticalScroll } 


A.3.10 Datei W110 


procedure WndStackT .Make; 
begin 

StackT.Make; 

ActiveWP:= nil; 

WndOK:= true; 

end; (-- Make } 


procedure WndStackT.OpenBaseWnd( XMin, XMax, YMin, YMax : integer ); 
var BaseWP : BaseWndPT; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


new( BaseWP ); 

BaseWP” „Make; 

BaseWP“.Open( XHiri, XMax, YMin, YMax ); 
if not WndOK then exit; 


ActiveWP:= BaseWP; 
if not Push( BaseWP ) then 
if WndCheck( WndStackFull ) then exit; 


end; (-- OpenBaseWnd } 
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procedure WndStackT.OpenWndi( XMin, XMax, YMin, YMax : integer; 
Name : WNameT ); 


var WiP : WndiPT; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


new( WIP ); 

W1P”.Make; 

WiP”“.Open( XMin, XMax, YMin, YMax, Name ); 
if not WndOK then exit; 


ActiveWP:= WIP; 
if not Push( WIP ) then 

if WndCheck( WndStackFull ) then exit; 
end; {-- OpenWndi } 
procedure WndStackT.OpenWnd2( XMin, XMax, YMin, YMax : integer; 

Name : WNameT; XStart, YStart : integer ); 

var W2P : Wnd2PT; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


new( W2P ); 

W2P” „Make; 

W2P”.Open( XMin, XMax, YMin, YMax, Name, XStart, YStart ); 
if not WndOK then exit; 


ActiveWP:= W2P; 
if not Push( W2P ) then 
if WndCheck( WndStackFull ) then exit; 


end; {-- OpenWnd2 } 
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procedure WndStackT.OpenWnd3( XMin, XMax, YMin, YMax : integer; 
Name : WNameT; XStart, YStart : integer ); 


var W3P : Wnd3PT; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


new( W3P ); 

W3P” „Make; 

W3P”.Open( XMin, XMax, YMin, YMax, Name, XStart, YStart ); 
if not WndOK then exit; 


ActiveWP:= W3P; 
if not Push( W3P ) then 
if WndCheck( WndStackFull ) then exit; 


end; {-- OpenWnd3 } 


procedure WndStackT.CloseWnd; 


var WP : StackElmT; 
BaseWP : BaseWndPT; 
WiP : WndiPT; 
W2P : Wnd2PT; 
W3P : Wnd3PT; 
begin 


if not WndOK then 
if WndCheck( WndNotOK ) then exit; 


WP:= Pop; 
if WP = nil then 
if WndCheck( WndStackEmpty ) then exit; 


case PreBaseWndPT( WP )“.ObjectType of 


BaseWnd : begin 
BaseWP:= BaseWndPT( WP ); 
BaseWP“.Close; if not WndOK then exit; 
BaseWP“.Kill; if not WndOK then exit; 
dispose( BaseWP ); 
end; 


Wnd1 : begin 
WiP:= WndiPT( WP ); 
wWiP*.Close; if not WndoK then exit; 
WiP*.Kill; if not WndOK then exit; 
dispose( WIP ); 
end; 
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Wnd2 : begin 
W2P:= Wnd2PT(C WP ); 
W2P”.Close; if not WndOK then exit; 
W2P”.Kill; if not WndOK then exit; 
dispose( W2P ); 
end; 


Wnd3 : begin 
W3P:= Wnd3PT( WP ); 
W3P*.Close; if not WndOK then exit; 
W3P”.Kill; if not WndOK then exit; 
dispose( W3P ); 
end; 


end;{-- case ) 
{-- ActiveWP mit dem obersten Fenster besetzten oder nil --) 
WP:= Pop; 
if WP <> nil then 
if Push( WP ) then; 
ActiveWP:= WP; 


end; {-- Close } 
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A.4 Kellerspeicher aus Kapitel 7 


A.4.1 Datei VStackU 


unit VStackU; 


{ 
StackT definiert einen Stack mit 10 Elementen. 
Push legt ein Element ab, liefert true wenn noch Platz 
fuer ein weiteres Element ist. 
Pop liefert eine Element, nil wenn Stack leer ist. 
} 
interface 
{-- Urtyp eines Stackelements ------------------ re 0000 > 
type StackElmT = object 
constructor Make; 
destructor Kill; virtual; 
end; (-- StackElmT } 
StackElmPT = *StackElmT; 
(-- Der Stack selber ---------------- --------- = - 7-7 4777777 7 777700007 B 
const MaxEntriesC = 10; 
type StackT = object 
Buffer : array[ 1..MaxEntriesCc ] of StackElmPT; 
Index : integer; 
constructor Make; 
destructor Kill; 
function Push( EP : StackElmPT ) : boolean; 
function Pop : StackElmPT; 
procedure Clear; 
end; {-- StackT } 
implementation 


{$1 VS150 3 X{-- Make, Kill fuer StackElmT } 
{$1 VS110 3 €-- Make, Kill } 

{$I 5S120 3 €-- Push, Pop } 

{$1 VS130 3 {-- Clear ) 


end. 


A.4.2 Datei VS150 


constructor StackElmT .Make; 
begin 
end; 


destructor StackElmT.Kill; 
begin 
end; 


A.4.3 Datei VS110 


{--- Implementierung StackT Make, Kill ----) 


constructor StackT.Make; 
begin 

Index:= 1; 

end; {-- Make ) 


destructor StackT.Kill; 
begin 
end; {-- Kill } 


A.4.4 Datei S120 


{--- Implementierung StackT Push, Pop --) 


function StackT.Push( EP : StackElmPT ) : boolean; 
begin 


if Index = MaxEntriesC then (-- Speicher voll. EP nicht eintragen } 
begin 
Push:= false; 
exit; 
end; 
Buffer[ Index ] := EP; 
inc Index ); 
Push:= true; 


end; (-- Push }) 
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function StackT.Pop : StackElmPT; 
begin 


if Index = 1 then {-- Speicher leer. nil zurueckliefern } 
begin 
Pop:= nil; 
exit; 
end; 


dec( Index ); 
Pop:= Buffer[ Index ]; 


end; {-- Pop } 


A.4.5 Datei VS130 


procedure StackT.Clear; 
var I : Integer; 


begin 

for I:= 1 to Pred( Index ) do 
Dispose( Buffer[ I ], Kill ); 

end; {-- Clear } 
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A.5 Fenstersystem aus Kapitel 8 


A.5.1 Datei Window 


unit windon; 

interface 

uses crt, general, VStackU; 

{$I W101.del > €-- Im InterfaceTeil gebrauchte Deklarationen } 


{-- Fehlerbehandlung --)} 


const WndWrongParam = 1; 
WndTooSmall = 2; 
WndNoMem = 3; 
WndWrongStat = 4; 
WndWrongStart =5; 
WndWrongScroll =6; 
WndStackEmpty = 7; 
WndStackFull = 8; 

const WndWrongParamt : string[ 17 ] = 'Falsche Parameter’; 
WndTooSmallC : string[ 16 ] = 'Fenster zu klein’; 
WndNoMemC : string[ 18 ] = 'Kein Speicher mehr’; 
WndWrongStatC : string[ 15 ] = ’Falscher Status’; 
WndWrongStartC : string[ 18 ] = ’Falsche Startwerte’; 
WndWrongScrollC : string[ 18 ] = ’Falsche Scrollbars’; 
WndStackEmptyC : string[ 26 ] 'Keine offenen Fenster mehr’; 


WndStackFullc : string[ 25 ] 'Kein Platz mehr auf Stack’; 
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type BaseWndT = object( StackElmT ) 
WXMin, WXMax, 


WYMin, WYMax : integer; 

XCur, YCur : Integer; (-- Cursorposition im Fenster } 

Status : WndStatusT; 

SaveP : LongArrayPT; {(-- gesicherter Bildschirmbereich } 
ColCount, LineCount : integer; 

Amount : integer; 


constructor Make( XMin, XMax, YMin, YMax : integer ); 
destructor Kill; virtual; 


procedure Allocate; virtual; 
procedure Activate; virtual; 
procedure DeActivate; virtual; 
procedure DeAllocate; virtual; 


procedure Open; 
procedure Close; 


end; (-- BaseWndT } 


BaseWndPT = *BaseWndT; 

[---- WNAIT  _------------- 440-0000 > 
type Wnd1T = object( BaseWndT ) 

WName : WNameT; 

FrameType : ( Standard, Alternate ); 

constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 

procedure Activate; virtual; 

procedure DeActivate; virtual; 


procedure SetStandard; 
procedure SetAlternate; 


end; (-- WndiT } 


Wndi1PT = “WndiT; 
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type Wnd2T 


object( WndiT ) 

WXStart, WYStart : integer; 

constructor Make( XMin, XMax, YMin, YMax : integer; Name : WNameT; 
XStart, YStart : integer ); 

procedure Allocate; virtual; 

procedure DeAllocate; virtual; 


end; {-- Wnd2T ) 


Wnd2PT = *undT; 


[---- 0. WndSystemT -------------------- 44-4000 


type WndSystemT 


object( StackT ) 


{-- ActiveWP zeigt auf das aktuelle Fenster oder ist nil --} 
ActiveWP : BaseWndPT; 


{-- WndOK wird von WndSystemT.WndError besetzt und sollte nach 
jeder Operation mit dem Fenstersystem abgefragt werden. 
Das Zuruecksetzen auf true ist Aufgabe des Nutzerprogramms --) 
WndOK : boolean; 


constructor Make; 


procedure OpenWnd( NewWndP : BaseWndPT ); 
function CloseWnd : boolean; 


procedure RePositionWnd( DeltaX, DeltaY : integer ); 


procedure DoFirst; virtual; 
procedure WndError( ErrorCode : byte ); virtual; 


end; {-- WndSystemT } 


WndSystemPT = *WndSystemT; 
var WndSystemP : WndSystemPT; 
implementation 
{$I W111.del > C-- ScreenT } 

{$I W112.del > {-- Konstanten fuer Rahmen } 
{$1I W100 > {-- Methoden BaseWndT } 

{$1I W101 > C-- Methoden Wnd1T > 

{$1I W102 > {-- Methoden Wnd2T > 

{$1I W110 > C-- Methoden WndStackT } 


end. 
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A.5.2 Datei W101.del 


(-- Bezeichnet den Zustand eines Fensters. Sinnvoll fuer 
erweiterte Fehlerpruefungen --} 


type WndStatusT 


= ( NotInitialized, {-- Make nicht erfolgreich > 
Made, {-- Make erfolgreich > 
Allocated, {-- Speicher zugewiesen } 
Active, {-- F. fuer Ausgabe aktiv } 
DeActive, {-- F. nicht fuer Ausgabe aktiv } 
DeAllocated ); {-- Speicher zurueckgegeben > 


{-- LongArrayT erlaubt die Interpretation eines Speicherbereiches als 
Folge von Einzelzeichen --) 


array[ 1..MaxInt ] of char; 
*LongArrayT; 


type LongArrayT 
LongArrayPT 


{-- WNameT aus Speicherplatzgruenden eingefuehrt --) 


type WNameT = string[ 20 ]; 


A.5.3 Datei Wi11.decl 


{-- Interpretation eines Hauptspeicherbereiches als Bildschirmspeicher } 


const ScrColumnst 80; (-- Spalten pro Zeile ) 


ScrLinest 25; {-- Bildschirmzeilen } 
type ScrCharT = record 
Ch : char; {-- Das eigentliche Zeichen } 
Attr : byte; {-- Attribut des Zeichens } 


end; {-- ScrCharT )} 


type ScrLineT array[ 1..ScrColumsC ] of ScrCharT; 


*ScreenT; 
array[ 1..ScrLinesCc ] of ScrLineT; 


type ScreenPT 
ScreenT 


{-- ScreenP zeigt auf Hardwarebildschirm. Wird im Initialisierungsteil 
von Window initialisiert --) 


var ScreenPp : ScreenPT; 
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A.5.4 Datei W112.del 


{-- Konstanten fuer Rahmen und 


(-- Einfacher Rahmen --) 


const UpperLeftiC 
LowerLeft1C 
UpperRight1C 
LowerRight1C 


Vertical1iC 
Horizontal1C 


{-- Doppelter Rahmen --) 


const UpperLeft2C 
LowerLeft2C 
UpperRight2C 
LowerRight2C 


Vertical2C 
Horizontal2C 


A.5.5 Datei W100 


constructor BaseWndT.Make( XMin, XMax, YMin, YMax : 


begin WndSystemP”“.DoFirst; 
Status:= NotInitialized; 


Scrollbars etc --) 


#218; 
#192; 
#191; 
#217; 


#179; 
#196; 


#201; 
#200; 
#187; 
#188; 


#186; 
#205; 


{-- RangeCheck der Parameter --} 
if c XMin < 1 ) or ( XMax > ScrColumstC ) or 
( YMin < 1 ) or ( YMin > ScrLinesC ) then 


begin 


WndSystemP“.WndError( WndWrongParam ); 


exit; 
end; 


integer ); 
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{-- Fenster muss mindestens 1x1 gross sein --}) 
if C XMax - XMin < 2 ) or ( YMax - YMin < 2 ) then 
begin 
WndSystemP”“.WndError( WndTooSmall ); 
exit; 
end; 


{-- Fensterkoordinaten speichern -- } 
WXMin:= XMin; WXMax:= XMax; 
WYMin:= YMin; WYMax:= YMax; 


Status:= Made; 
end; {-- Make } 


procedure BaseWndT.Allocate; 
var I, J : integer; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --} 
if not ( Status in [ Made, DeAllocated ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


{-- Feststellen des zu sichernden Bildschirmbereiches --) 
ColCount:= 2*succ( WXMax-WXMin ); {-- bytes pro Zeile } 
LineCount:= succ( WYMax-WYMin ); {-- Anzahl Zeilen } 
Amount:= LineCount * ColCount; 


{-- hier waere die Verwendung von Fail moeglich, diese Loesung ist 
aber besser, da ein spezifischer Fehlercode erzeugt wird } 


if MaxAvail < Amount then 
begin 
WndSystemP“.WndError( WndNoMem ); 
exit; 
end; 


GetMem( SaveP, Amount ); 


{-- Zeilenweise in SaveP”“ ablegen --) 


J:= 1; 
for I:= WYMin to WYMax do 
begin 


move( ScreenP“[ I, WXMin ], SaveP’[ J ], ColCount ); 
J:= J + ColCount; 


Status:= Allocated; 
end; (-- Allocate } 
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procedure BasewWndT.Activate; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --} 
if not ( Status in [ Allocated, DeActive ] ) then 
begin 
WndSystemP*.WndError( WndWrongStat ); 
exit; 
end; 


(-- Fenster oeffnen und Cursor auf letzte Position --} 
cert.Window( WXMin, WYMin, WXMax, WYMax ); 
gotoXY(C XCur, YCur ); 


Status:= Active; 
end; {-- Activate ) 


procedure BaseWndT ..DeActivate; 
begin WndSystemP”“.DoFirst; 


{-- Statuspruefung --}) 
if Status <> Active then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


XCur:= WhereX; YCur:= WhereY; 
ert.Window( 1, 1, ScrColumnsC, ScrLinestC ); 


Status:= DeActive; 
end; {-- DeActivate ) 


procedure BaseWndT.DeAllocate; 
var I, J : integer; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --) 
if not ( Status in [ Allocated, DeActive ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


{-- Zeilenweise aus SaveP”“ holen --} 
Jı= 1; 
for I:= WYMin to WYMax do 
begin 
move( SaveP”[ J ], ScreenP”“[ I, WXMin ], ColCount ); 
J:= J + ColCount; 
end; 
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FreeMem( SaveP, Amount ); 
Status:= DeAllocated; 
end; {-- DeAllocate )} 


destructor BaseWndT.Kill; 
begin WndSystemP“.DoFirst; 


{-- Statuspruefung --} 
if not ( Status in [ Made, DeAllocated ] ) then 
begin 
WndSystemP“.WndError( WndWrongStat ); 
exit; 
end; 


end; {-- Kill } 


procedure BaseWndT .Open; 
begin WndSystemP“.DoFirst; 
Allocate; 

Activate; 

end; {-- Open } 


procedure BaseWndT.Close; 
begin WndSystemP“.DoFirst; 
DeActivate; 

DeAllocate; 

end; (-- Close } 


A.5.6 Datei W101 


constructor Wnd1T.Make( XMin, XMax, YMin, YMax : integer; Name : WNameT ); 
begin WndSystemP“.DoFirst; 


if XMax > ScrColumsC - 2 then 
begin 
WndSystemP“.WndError( WndWrongParam ); 
exit; 
end; 


BaseWndT.Make( pred( XMin ), succ( XMax ), pred( YMin ), succ( YMax ) ); 


{-- Namen speichern --) 
WName:= Name; 


FrameType:= Alternate; 
end; (-- Make } 


procedure Wnd1T.Activate; 
begin WndSystemP”“.DoFirst; 
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BaseWndT.Activate; 
SetAlternate; 
end; {-- Activate )} 


procedure WndiT.DeActivate; 
begin WndSystemP“.DoFirst; 
SetStandard; 

BaseWndT .DeActivate; 

end: 


procedure Wndi1T.SetStandard; 


var | : Integer; 
XSpan, YSpan : integer; 
DspName : WNameT; 
var SaveCurX, SaveCurY : integer; 


begin WndSystemP”“.DoFirst; 


{-- Cursor Sichern, am Ende der Prozedur wiederherstellen } 
SaveCurX:= WhereX; SaveCurY:= WhereY; 


crt.Window( WXMin, WYMin, succ( WXMax ), WYMax ); 


XSpan:= succ( WXMax - WXMin ); {-- Spaltenzahl )} 
YSpan:= succ( WYMax - WYMin ); {-- Zeilenzahl ) 


gotoXY( 1,1); 

write( UpperLeftiC ); 

for I:= 2 to pred( XSpan ) do 
write( HorizontaliC ); 

write( UpperRightiC ); 


for I:= 2 to pred( YSpan ) do 
begin 
gotoXY( 1, 1); 
write( VerticaliC ); 
gotoXY( XSpan, I ); 
write( VerticaliC ); 
end; 


gotoXY( 1, YSpan ); 

write( LowerLeftiC ); 

for I:= 2 to pred( XSpan ) do 
write( HorizontaliC ); 

write( LowerRightiC ); 


{-- Namen eintragen --) 

DspName:= copy( WName, 1, XSpan-2 ); {-- Maximale Laenge ist XSpan-2 )} 
gotoXY( succ( trunc( succ( XSpan )/2 - length( DspName )/2 ) ), 1); 
write( DspName ); 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 
gotoXY( SaveCurX, SaveCurY ); 


end; {-- SetStandard } 
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procedure Wnd1T.SetAlternate; 
var I 

XSpan, YSpan 

DspName 


var SaveCurX, SaveCurY 


begin WndSystemP“.DoFirst; 


integer; 
integer; 
WNameT ; 


: Integer; 


{-- Cursor Sichern, am Ende der Prozedur wiederherstellen } 
SaveCurX:= WhereX; SaveCurY:= WhereY; 


ert.Window( WXMin, WYMin, succ( WXMax ), WYMax ); 


XSpan:= succ( WXMax - WXMin ); {-- Spaltenzahl ) 
YSpan:= succ( WYMax - WYMin ); (-- Zeilenzahl ) 


gotoXY( 1, 1 ); 

write( UpperLeft2C ); 

for l:= 2 to pred( XSpan ) do 
write( Horizontal2C ); 

writeC UpperRight2C ); 


for I:= 2 to pred( YSpan ) do 
begin 
gotoXY( 1, 1); 
write( Vertical2C ); 
gotoXY( XSpan, I ); 
write( Vertical2C ); 
end; 


gotoXY( 1, YSpan ); 

write( LowerlLeft2C ); 

for I:= 2 to pred( XSpan ) do 
write(C Horizontal2C ); 

write( LowerRight2C ); 


(-- Namen eintragen --)} 


DspName:= copy( WName, 1, XSpan-2 ); (-- Maximale Laenge ist XSpan-2 } 
gotoXY( succ( trunc( succ( XSpan )/2 - length( DspName )/2 ) ), 1); 


write( DspName ); 


ert.Window( succ( WXMin ), succ( WYMin ), pred( WXMax ), pred( WYMax ) ); 


gotoXY( SaveCurX, SaveCurY ); 


end; (-- SetAlternate ) 
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A.5.7 Datei W102 


constructor Wnd2T.Make( XMin, XMax, YMin, YMax : integer; Name : 


XStart, YStart : integer ); 
begin WndSystemP“.DoFirst; 


(-- RangeCheck Parameter --) 

if ( XStart < 2 ) or ( YStart < 2 ) then 
begin 
WndSystemP“ .WndError( WndWrongStart ); 
exit; 
end; 


WXStart: 
WYStart: 


= XStart; 

= YStart; 

wWnd1T.Make( XMin, XMax, YMin, YMax, Name ); 
end; {-- Make ) 


procedure Wnd2T.Allocate; 
var XMinDelta, XMaxDelta, 


YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 


TempYMin, TempYMax : integer; 
var Done : boolean; 

D : integer; 
var TempW : Wnd1T; 


begin WndSystemP”“.DoFirst; 


XMinDelta:= Sign( succ( WXMin ) - WXStart ); 
XMaxDelta:= Sign( pred( WXMax ) - WXStart ); 
YMindelta:= Sign( succ( WYMin ) - WYStart ); 
YMaxDelta:= Sign( pred( WYMax ) - WYStart ); 
TempXMin:= WXStart + XMinDelta; 


WXStart + XMaxDelta; 
WYStart + YMinDelta; 
WYStart + YMaxDelta; 


TempXMax: 
TempYMin: 
TempYMax: 


TempW.Make( TempXMin, TempXMax, TempYMin, TempYMax, WName ); 
TempW .Open; 

Done:= false; 

D:= 20; 


WNameT; 
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while not Done do 
begin 
Done:= true; 


Delay( D ); 
D:= 0; 

TempW.Close; 
TempW.Kill; 


{-- Neue Koordinaten berechnen --) 


if TempXMin <> succ( if TempXMin <> succ( WXMin ) then 
begin 
inc( TempXMin, XMinDelta ); 
inc D,5 ); 
Done:= false; 
end; 


if TempXMax <> pred( WXMax ) then 
begin 
inc( TempXMax, XMaxDelta ); 
inc D,5); 
Done:= false; 


end; 

if TempYMin <> succ( WYMin ) then 
begin 
inc( TempYMin, YMinDelta ); 
inc D,5); 
Done:= false; 
end; 


if TempYMax <> pred( WYMax ) then 
begin 
inc( TempYMax, YMaxDelta ); 
incl D, 5 ); 
Done:= false; 
end; 


TempW.Make( TempXMin, TempXMax, TempYMin, TempYMax, WName ); 


TempW.Open; 
end; (-- while not Done } 


{-- Temporaeres Fenster befindet sich jetzt an der Stelle 
des aktuellen Fensters. Temp loeschen und aktuelles Fenster oeffnen } 


TempW.Close; 
TempW.Kill; 
Wnd1T.Allocate; 


end; {-- Allocate } 


A.5S Fenstersystem aus Kapitel 8 205 


procedure Wnd2T.DeAllocate; 


var XMinDelta, XMaxDelta, 
YMinDelta, YMaxDelta, 
TempXMin, TempXMax, 


TempYMin, TempYMax : integer; 
var Done : boolean; 

D : integer; 
var TempW : WndiT; 


begin WndSystemP“.DoFirst; 


XMindelta: 
XMaxDelta: 
YMinDelta: 
YMaxDelta: 


Sign( WXStart - WXMin ); 
Sign( WXStart - WXMax ); 
Sign( WYStart - WYMin ); 
Sign( WYStart - WYMax ); 


WXMin; 
WXMax; 
WYMin; 
WYMax; 


TempXMin: 
TempXMax: 
TempYMin: 
TempYMax: 


Wnd1T.DeAllocate; 
Done:= false; 


while not Done do 
begin 
Done:= true; 
D:= 0; 


if C TempXMax = TempXMin ) and ( TempYMax = TempYMin ) then 
begin {-- Verschieben --) 


D:= 20; 

if TempXMin <> WXStart then 
begin 
inc( TempXMin, XMinDelta ); 
inc( TempXMax, XMaxDelta ); 
Done:= false; 
end; 


if TempYMax <> WYstart then 
begin 
inc( TempYMin, YMinDelta ); 
inc( TempYMax, YMaxDelta ); 
Done:= false; 
end; 


end {(-- Verschieben } 
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else 


begin (-- Verkleinern } 
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if ( XMinDelta > O ) and ( TempXMin <> WXStart ) then 


if 


if 


if 


end; 


begin 

if TempXMax - TempXMin > O0 then 
inc( TempXMin, XMinDelta ); 

incl D, 5 ); 

Done:= false; 

end; 


( XMaxDelta < 0 ) and ( TempXMax <> 

begin 

if TempXMax - TempXMin > O then 
inc( TempXMax, XMaxDelta ); 

incl D, 5); 

Done:= false; 

end; 


( YMinDelta > 0 ) and ( TempYMin <> 

begin 

if TempYMax - TempYMin > O then 
inc( TempYMin, YMinDelta ); 

inc( D, 5); 

Done:= false; 

end; 


( YMaxDelta < 0 ) and ( TempYMax <> 

begin 

if TempYMax - TempYMin > O then 
inc( TempYMax, YMaxDelta ); 

incl D,5 ); 

Done:= false; 

end; 


TempW.Make( TempXMin, TempXMax, TempYMin, 
TempW.Open; 

Delay( D ); 

TempW.Close; 

TempW.Kill; 

end; {-- while } 


end; {-- 


DeAllocate } 


WXStart ) then 


WYStart ) then 


WYStart ) then 


TempYMax, WName ); 
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A.5.8 Datei W110 


constructor WndSystemT .Make; 
begin 

StackT.Make; 

ActiveWP:= nil; 

WndOK:= true; 


ScreenP:= ptr( GetScreenBase, 0 ); 


end; {-- Make ) 


procedure WndSystemT.OpenWnd( NewWndP : 


begin DoFirst; 


if ActiveWP <> nil then 

begin 

ActiveWP” .DeActivate; 

if not Push( ActiveWP ) then 
begin 
WndError( WndStackFull ); 
exit; 
end; 

end; 


ActiveWP:= NewWndP; 
ActiveWP“.Open; 
end; {-- OpenWnd } 


function WndSystemT.CloseWnd : boolean; 


BaseWndPT ); 


var WorkWP : BaseWndPT; 


begin DoFirst; 


if ActiveWP = nil then 


begin 

ClosewWnd:= false; 

exit; 

end; 
ActiveWP”“.Close; 


dispose( ActiveWP, Kill ); 


ActiveWP:= BaseWndPT( Pop ); 
if ActiveWP <> nil then 
ActiveWP”“ .Activate; 


CloseWnd:= true; 
end; {-- CloseWnd } 
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procedure WndSystemT.RePositionWnd( DeltaX, DeltaY : integer ); 


BaseWndT; 
integer; 


var Swapk 
SaveXCur, SaveYCur 


begin DoFirst; 
if ActiveWP = nil then exit; {-- kein Fenster offen } 


{-- Altes Fenster deaktivieren, um Cursorposition zu speichern --) 
ActiveWP“.DeActivate; 


{-- Temporaeres Fenster zum Zwischenspeichern des aktuellen 
Fensters erzeugen --} 


with ActiveWP”“ do 
SwapW.Make( WXMin, WXMax, WYMin, WYMax ); 


(-- Aktuellen Fensterbereich sichern } 
SwapW.Open; 


{-- Auf dem Heap befindet sich jetzt eine Kopie des aktuellen Fensterinhalts )} 
(-- Aktuelles Fenster schliessen und an neuen Koordinaten oeffnen --) 


with ActiveWP“ do 
begin 
DeAllocate; 
inc WXMin, DeltaX ); 
inc( WXMax, DeltaX ); 
inc( WYMin, DeltaY ); 
inc WYMax, DeltaY ); 
SaveXCur:= XCur; SaveYCur:= YCur; 
Allocate; 
XCur:= SaveXCur; YCur:= SaveYCur; 
end; 


{-- nun den gesicherten Bildschirminhalt auf die neuen Koordinaten kopieren } 


with SwapW do 
begin 
inc( WXMin, DeltaX ); 
inc WXMax, DeltaX ); 
inc( WYMin, DeltaY ); 
inc( WYMax, DeltaY ); 
Close; 
end; 

SwapW.Kill; 


ActiveWP“.Activate; 
end; {-- RePositionWnd } 


procedure WndSystemT.DoFirst; 
begin 
end; {-- DoFirst )} 
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procedure WndSystemT.WndError( ErrorCode : byte ); 
begin 


(-- Standardmaessig wird eine Fehlermeldung ausgegeben und WndOK auf false 
gesetzt --) 


case ErrorCode of 


WndWrongParam : writeln( WndWrongParaml ); 
WndTooSmall : writelnf WndTooSmallC ); 
WndNoMem : writeln( WndNoMemC ); 
WndWrongStat : writeln( WndWrongStatC ); 
WndWrongStart : writeln( WndWrongStartC ); 
WndWrongScroll : writeln( WndWrongScrollC ); 
WndStackEmpty : writeln( WndStackEmptyC ); 
WndStackFull : writeln( WndStackFullc ); 


end; {-- case } 
WndoK:= false; 


end; (-- WndError )} 
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